Network Working Group E. Carrara
Request for Comments: 4563 KTH
Category: Standards Track V. Lehtovirta
K. Norrman
Ericsson
June 2006
Network Working Group E. Carrara
Request for Comments: 4563 KTH
Category: Standards Track V. Lehtovirta
K. Norrman
Ericsson
June 2006
The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)
多媒体互联网密钥（MIKEY）中通用扩展有效负载的密钥ID信息类型
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol. This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project.
此备忘录为多媒体互联网密钥（MIKEY）协议中的通用扩展有效负载指定了一种新类型（密钥ID信息类型）。例如，这用于第三代合作伙伴项目中指定的多媒体广播/多播服务。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Rationale .......................................................2
3. Relations to MIKEY and GKMARCH ..................................3
4. The Key ID Information Type for the General Extension Payload ...4
5. Empty Map Type Definition for the CS ID Map Type ................5
6. Transport Considerations ........................................5
7. Security Considerations .........................................5
8. IANA Considerations .............................................7
9. Acknowledgements ................................................7
10. References .....................................................8
10.1. Normative References ......................................8
10.2. Informative References ....................................8
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Rationale .......................................................2
3. Relations to MIKEY and GKMARCH ..................................3
4. The Key ID Information Type for the General Extension Payload ...4
5. Empty Map Type Definition for the CS ID Map Type ................5
6. Transport Considerations ........................................5
7. Security Considerations .........................................5
8. IANA Considerations .............................................7
9. Acknowledgements ................................................7
10. References .....................................................8
10.1. Normative References ......................................8
10.2. Informative References ....................................8
The Third Generation Partnership Project (3GPP) is currently involved in the development of a multicast and broadcast service, the Multimedia Broadcast/Multicast Service (MBMS), and its security architecture [MBMS].
第三代合作伙伴关系项目（3GPP）目前参与多播和广播服务、多媒体广播/多播服务（MBMS）及其安全架构（MBMS）的开发。
[MBMS] requires the use of the Multimedia Internet KEYing (MIKEY) Protocol [RFC3830] to convey the keys and related security parameters needed to secure multimedia that is multicast or broadcast.
[MBMS]需要使用多媒体互联网密钥（MIKEY）协议[RFC3830]来传输保护多播或广播多媒体所需的密钥和相关安全参数。
One of the requirements that MBMS puts on security is the ability to perform frequent updates of the keys. The rationale behind this is that it will be costly for subscribers to re-distribute the decryption keys to non-subscribers. The cost for re-distributing the keys using the unicast channel should be higher than the cost of purchasing the keys for this scheme to have an effect. To implement this, MBMS uses a three-level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key. As illustrated in the section below, MBMS has the need to identify which types of keys are involved in the MIKEY message and their identity.
MBMS对安全性的要求之一是能够频繁更新密钥。这背后的基本原理是订阅者将解密密钥重新分发给非订阅者的成本很高。使用单播信道重新分发密钥的成本应高于购买密钥的成本，以使该方案产生效果。为了实现这一点，MBMS使用三级密钥管理，将组密钥分发给客户端，并能够通过按下新的组密钥来重新设置密钥。如以下部分所示，MBMS需要识别MIKEY消息中涉及的密钥类型及其标识。
This memo specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of keys involved.
此备忘录为MIKEY中的通用扩展有效负载指定了一个新类型，以标识所涉及密钥的类型和标识。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
An application where this extension is used is MBMS key management. The key management solution adopted by MBMS uses three-level key management. The keys are used in the way described below. "Clients" refers to the clients who have subscribed to a given multicast/broadcast service.
使用此扩展的应用程序是MBMS密钥管理。MBMS采用的密钥管理解决方案采用三级密钥管理。按键的使用方式如下所述。“客户端”指已订阅给定多播/广播服务的客户端。
* The MBMS User Key (MUK), a point-to-point key between the multicast server and each client.
* MBMS用户密钥（MUK），多播服务器和每个客户端之间的点对点密钥。
* The MBMS Service Key (MSK), a group key between the multicast server and all the clients.
* MBMS服务密钥（MSK），多播服务器和所有客户端之间的组密钥。
* The MBMS Traffic Key (MTK), a group traffic key between the multicast server and all clients.
* MBMS通信密钥（MTK），多播服务器和所有客户端之间的组通信密钥。
The Traffic Keys are the keys that are regularly updated.
交通钥匙是定期更新的钥匙。
The point-to-point MUK (first-level key) is shared between the multicast server and the client via means defined by MBMS [MBMS]. The MUK is used as a pre-shared key to run MIKEY with the pre-shared key method [RFC3830], and to deliver (point-to-point) the MSK. The same MSK is pushed to all the clients, to be used as a (second-level) group key.
点到点MUK（第一级密钥）通过MBMS[MBMS]定义的方式在多播服务器和客户端之间共享。MUK用作预共享密钥，以使用预共享密钥方法[RFC3830]运行MIKEY，并交付（点对点）MSK。将相同的MSK推送到所有客户端，用作（第二级）组密钥。
Then, the MSK is used to push to all the clients an MTK (third-level key), the actual group key that is used for the protection of the media traffic. For example, the MTK could be the master key for the Secure Real-time Transport Protocol (SRTP) [RFC3711] in the streaming case.
然后，MSK用于向所有客户端推送MTK（第三级密钥），MTK是用于保护媒体流量的实际组密钥。例如，在流传输情况下，MTK可以是安全实时传输协议（SRTP）[RFC3711]的主密钥。
A Key Domain identifier defines the domain where the group keys are valid or applicable. For example, it may define a specific service provider.
密钥域标识符定义组密钥有效或适用的域。例如，它可以定义特定的服务提供者。
To allow the key distribution described above, an indication of the type and identity of keys being carried in a MIKEY message is needed. This indication is carried in a new Type of the General Extension Payload in MIKEY.
为了允许上述密钥分发，需要指示MIKEY消息中携带的密钥的类型和标识。这一指示在MIKEY的新型通用扩展有效载荷中进行。
It is necessary to specify what Crypto Session ID (CS ID) map type is associated with a given key. There are cases (for example, the download case in MBMS) where the required parameters are signalled in-band (each downloaded Digital Rights Management Content Format object [DCF] contains the necessary parameters needed by the receiver to process it). Since the parameters are not transported by MIKEY, this implies that a CS ID map type needs to be registered to the "empty map", as defined in Table 3, which is to be used when the map/policy information is conveyed outside of MIKEY.
有必要指定与给定密钥关联的加密会话ID（CS ID）映射类型。在某些情况下（例如，以MBMS为单位的下载情况），所需的参数在频带内发出信号（每个下载的数字版权管理内容格式对象[DCF]包含接收机处理它所需的必要参数）。由于参数不是由MIKEY传输的，这意味着CS ID映射类型需要注册到“空映射”，如表3中所定义，当映射/策略信息在MIKEY外部传输时使用。
According to [RFC3830], MIKEY is a registration protocol that supports re-keying for unicast in the terms of the MSEC Group Key Management Architecture [RFC4046]. MBMS uses MIKEY both as a registration protocol and a re-key protocol, and the specified extension implements the necessary additions to [RFC3830] that allows MIKEY to function both as a unicast and multicast re-key protocol in the MBMS setting.
根据[RFC3830]，MIKEY是一种注册协议，根据MSEC组密钥管理体系结构[RFC4046]，它支持单播的密钥重设。MBMS将MIKEY用作注册协议和重设密钥协议，指定的扩展实现了[RFC3830]的必要补充，允许MIKEY在MBMS设置中同时用作单播和多播重设密钥协议。
The General Extension payload in MIKEY is defined in Section 6.15 of [RFC3830]. The General Extension payload type (Key ID Information) defined in the present document is not restricted to MBMS. Applications using this General Extension payload type may define new Key ID types, and these applications MUST define the semantics and usage of the Key ID Type sub-payloads according to Section 8. The MBMS use of the Key ID Type sub-payloads, defined in Table 2, is specified in [MBMS].
[RFC3830]第6.15节定义了MIKEY中的一般扩展有效载荷。本文档中定义的一般扩展有效负载类型（密钥ID信息）不限于MBMS。使用此通用扩展有效负载类型的应用程序可以定义新的密钥ID类型，并且这些应用程序必须根据第8节定义密钥ID类型子有效负载的语义和用法。表2中定义的密钥ID类型子有效载荷的MBMS使用在[MBMS]中规定。
The Key ID Information Type (Type 3) formats the General Extension payload as follows:
密钥ID信息类型（类型3）将通用扩展有效负载格式化如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Key ID Information General Extension Payload
图1。密钥ID信息通用扩展有效负载
Next Payload and Length are defined in Section 6.15 of [RFC3830].
[RFC3830]第6.15节定义了下一个有效载荷和长度。
* Type (8 bits): identifies the type of the General Extension Payload [RFC3830]. This memo adds Type 3 to the ones already defined in [RFC3830].
* 类型（8位）：标识通用扩展有效负载的类型[RFC3830]。本备忘录将类型3添加到[RFC3830]中已定义的类型。
Type | Value | Comments
------------------------------------------------------------
Key ID | 3 | information on type and identity of keys
Type | Value | Comments
------------------------------------------------------------
Key ID | 3 | information on type and identity of keys
Table 1. Definition of the New General Extension Payload
表1。新的通用扩展有效载荷的定义
* Key ID Information (variable length): the general payload data transporting the type and identifier of a key. This field is formed by Key ID Type sub-payloads as specified below.
* 密钥ID信息（可变长度）：传输密钥类型和标识符的一般有效负载数据。该字段由密钥ID类型子有效载荷构成，如下所述。
The Key ID Type sub-payload is formatted as follows:
密钥ID类型子有效负载的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Type ! Key ID Length ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Type ! Key ID Length ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The Key ID Type Sub-payload
图2。密钥ID类型为子有效负载
* Key ID Type (8 bits): describes the type of the key ID. Predefined types are listed in Table 2.
* 密钥ID类型（8位）：描述密钥ID的类型。表2中列出了预定义的类型。
Key ID Type | Value | Comment
-----------------------------------------------------------
MBMS Key Domain ID | 0 | ID of the group key domain
MBMS Service Key ID | 1 | ID of the group key
MBMS Traffic Key ID | 2 | ID of the group traffic key
Key ID Type | Value | Comment
-----------------------------------------------------------
MBMS Key Domain ID | 0 | ID of the group key domain
MBMS Service Key ID | 1 | ID of the group key
MBMS Traffic Key ID | 2 | ID of the group traffic key
Table 2. Type definitions for Key IDs
表2。密钥ID的类型定义
* Key ID Length (8 bits): describes the length of the Key ID field in octets.
* 密钥ID长度（8位）：以八位字节为单位描述密钥ID字段的长度。
* Key ID (variable length): defines the identity of the key.
* 密钥ID（可变长度）：定义密钥的标识。
Note that there may be more than one Key ID Type sub-payload in an extension, and that the overall length (i.e., the sum of lengths of all Key ID Type sub-payloads) of the Key ID information field cannot exceed 2^16 - 1 octets.
请注意，扩展中可能有多个密钥ID类型子有效载荷，并且密钥ID信息字段的总长度（即，所有密钥ID类型子有效载荷的长度之和）不能超过2^16-1个八位字节。
When the security policy information is conveyed outside of MIKEY, the CS ID map type is set to a value defined in Table 3 to indicate "empty map". In this case, there MUST NOT be any Security Policy payload present in the message.
当安全策略信息在MIKEY外部传输时，CS ID映射类型设置为表3中定义的值，以指示“空映射”。在这种情况下，消息中不得存在任何安全策略有效负载。
CS ID map type | Value | Comments
-------------------------------------------------------------
Empty map | 1 | Used when the map/policy information
| | is conveyed outside of MIKEY
CS ID map type | Value | Comments
-------------------------------------------------------------
Empty map | 1 | Used when the map/policy information
| | is conveyed outside of MIKEY
Table 3. Definition of the CS ID Map Type.
表3。CS ID映射类型的定义。
As specified in Section 7 of [RFC3830], the underlying transport of the MIKEY protocol has to be defined for each type of transport. When the Key-ID payload is used with MBMS, the transport is UDP, and the usage of MIKEY over UDP in the MBMS setting is defined in [MBMS].
如[RFC3830]第7节所述，必须为每种传输类型定义MIKEY协议的基础传输。当密钥ID有效负载与MBMS一起使用时，传输为UDP，并且在[MBMS]中定义了MBMS设置中通过UDP使用MIKEY。
The usage of MIKEY for updating the traffic encryption key (MTK) in the broadcast manner, described in Section 2, deviates from the way MIKEY [RFC3830] was originally designed. There are two main points that are related to the security of the described usage.
第2节中描述的使用MIKEY以广播方式更新流量加密密钥（MTK）的方式与MIKEY[RFC3830]最初的设计方式不同。有两个要点与所描述使用的安全性相关。
First, the delivery of the MTK is not source origin authenticated, but rather protected by a group MAC, keyed by the group key (MSK). The threat this raises is that users that are part of the group are able to send fake MTK messages to other group members. The origin of the MTK messages is a node inside the core network, and the trust model used in MBMS is that only trusted traffic is allowed to be sent (from within the operator's network) on the MBMS bearers. However, there is always the risk that traffic is injected on the air interface between the base stations and the user equipment. It is possible for members of the group (i.e., with access to the MSK) to spoof MTK updates to other members of the group. 3GPP decided that the technical difficulties and costs involved in performing such an attack are large enough compared to the expected gain for the attacker, that the risk was deemed acceptable. Note that, since the delivery of the MTK is not source origin authenticated, there is nothing gained by adding source origin authentication to the RTP streams (e.g., using SRTP-TESLA [RFC4383]). Hence, the current use of the specified extension is not compatible with SRTP-TESLA, which requires source origin authentication of the integrity key.
首先，MTK的交付不是源站验证，而是由组密钥（MSK）加密的组MAC进行保护。这带来的威胁是，属于该组的用户能够向其他组成员发送虚假MTK消息。MTK消息的来源是核心网络内的一个节点，MBMS中使用的信任模型是只允许在MBMS承载器上发送（来自运营商网络内）受信任的通信量。然而，始终存在在基站和用户设备之间的空中接口上注入流量的风险。该组的成员（即，有权访问MSK）可以向该组的其他成员伪造MTK更新。3GPP认为，与攻击者的预期收益相比，执行此类攻击所涉及的技术困难和成本足够大，因此认为风险是可以接受的。注意，由于MTK的交付未经源站认证，因此将源站认证添加到RTP流（例如，使用SRTP-TESLA[RFC4383]）不会获得任何好处。因此，指定扩展的当前使用与SRTP-TESLA不兼容，SRTP-TESLA要求对完整性密钥进行源站身份验证。
Note that in MBMS the MSK is protected end-to-end, from the multicast server to the clients, using a client-unique key MUK, but the MTK is delivered under protection by the group key MSK, so source origin authentication is not achieved.
请注意，在MBMS中，MSK使用客户端唯一密钥MUK从多播服务器端到端地受到保护，但MTK是在组密钥MSK的保护下交付的，因此无法实现源源认证。
Secondly, the delivery of the MTK is separated from the delivery of the security policy. The security policy is delivered with the MSK. The delivery of the MTKs is assumed to be frequent (some scenarios require the delivery of MTKs to be as frequent as a few seconds apart). This would imply that the cost (in terms of bandwidth) would be very high if the security policy was delivered together with each MTK. Furthermore, the security policy parameters of the streaming session are not anticipated to change during the session, even though there would be an update of the MTK. It was decided in 3GPP that there was no need for updating the policy during an ongoing session, and that the cost of allowing such a feature, only to be on the safe side, would be too high. On the other hand, updating the security policy during an ongoing session would be possible by updating the MSK.
其次，MTK的交付与安全策略的交付是分开的。安全策略随MSK一起提供。假设MTK的交付是频繁的（某些情况要求MTK的交付间隔几秒钟）。这意味着，如果安全策略与每个MTK一起交付，成本（在带宽方面）将非常高。此外，流会话的安全策略参数预计在会话期间不会改变，即使MTK会有更新。3GPP决定在正在进行的会话期间不需要更新策略，并且为了安全起见，允许这种功能的成本太高。另一方面，通过更新MSK，可以在正在进行的会话期间更新安全策略。
The Empty map type used when the security policy is delivered in band relies on the security provided by DCF [DCF], and MIKEY is, in this case, only used to provide the master key for the DCF processing.
在带内交付安全策略时使用的空映射类型依赖于DCF[DCF]提供的安全性，在这种情况下，MIKEY仅用于为DCF处理提供主密钥。
According to Section 10 of RFC 3830, IETF consensus is required to register values in the range 0-240 in the Type namespace of the MIKEY General Extension Payload and the CS ID map type namespace of the Common Header Payload.
根据RFC 3830的第10节，IETF共识要求在MIKEY通用扩展有效载荷的类型命名空间和公共头有效载荷的CS ID映射类型命名空间中注册0-240范围内的值。
A new value in the MIKEY General Extension Payload Type name space has been registered for this purpose. The registered value for Key ID is 3 according to Section 4.
为此，已在MIKEY General Extension有效负载类型名称空间中注册了一个新值。根据第4节，密钥ID的注册值为3。
Also, the value 1 has been registered for the Empty map in the existing CS ID map namespace of the Common Header Payload, as specified in Table 3, in Section 5.
此外，如第5节中的表3所示，值1已在公共头有效负载的现有CS ID映射命名空间中为空映射注册。
The new name space for the following field in the Key ID information sub-payload (from Sections 4 and 5) has been established and will be managed by IANA:
密钥ID信息子有效载荷（第4节和第5节）中以下字段的新名称空间已经建立，并将由IANA管理：
* Key ID Type
* 密钥ID类型
The IANA has registered the pre-defined types of Table 2 for this namespace. IANA will also manage the definition of additional values in the future. Values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus, and values in the range 241-255 are reserved for Private Use, according to [RFC2434].
IANA已为此命名空间注册了表2的预定义类型。IANA还将在未来管理附加值的定义。根据[RFC2434]，每个名称空间0-240范围内的值应通过IETF协商一致程序批准，241-255范围内的值保留供私人使用。
We would like to thank Fredrik Lindholm.
我们要感谢弗雷德里克·林德霍姆。
[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月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security; Security of Multimedia Broadcast/Multicast Service".
[MBMS]3GPP TS 33.246，“技术规范第三代合作伙伴项目；技术规范组服务和系统方面；安全性；多媒体广播/多播服务的安全性”。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[DCF] Open Mobile Alliance, OMA-DRM-DCF-V2_0-20050329-C, "DRM Content Format V2.0", Candidate Version 2.0 - 29 March 2005.
[DCF]开放移动联盟，OMA-DRM-DCF-V2_0-20050329-C，“DRM内容格式V2.0”，候选版本2.0-2005年3月29日。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383]Baugher，M.和E.Carrara，“在安全实时传输协议（SRTP）中使用定时高效流丢失容忍认证（TESLA）”，RFC 4383，2006年2月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046]Baugher，M.，Canetti，R.，Dondeti，L.，和F.Lindholm，“多播安全（MSEC）组密钥管理体系结构”，RFC 4046，2005年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
Authors' Addresses
作者地址
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
瑞典斯德哥尔摩皇家理工学院Elisabetta Carrara
EMail: carrara@kth.se
EMail: carrara@kth.se
Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland
Vesa Lehtovirta Ericsson Research 02420 Jorvas芬兰
Phone: +358 9 2993314
EMail: vesa.lehtovirta@ericsson.com
Phone: +358 9 2993314
EMail: vesa.lehtovirta@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
卡尔·诺尔曼·爱立信研究所SE-16480瑞典斯德哥尔摩
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。