Network Working Group P. Nikander
Request for Comments: 5205 Ericsson Research NomadicLab
Category: Experimental J. Laganier
DoCoMo Euro-Labs
April 2008
Network Working Group P. Nikander
Request for Comments: 5205 Ericsson Research NomadicLab
Category: Experimental J. Laganier
DoCoMo Euro-Labs
April 2008
Host Identity Protocol (HIP) Domain Name System (DNS) Extension
主机标识协议（HIP）域名系统（DNS）扩展
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).
本文档指定了域名系统（DNS）的新资源记录（RR），以及如何将其与主机标识协议（HIP）一起使用。此RR允许HIP节点在DNS中存储其主机标识（HI，节点公钥-私钥对的公共组件）、主机标识标签（HIT，其公钥的截断散列）及其集合服务器（RVS）的域名。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Simple Static Singly Homed End-Host . . . . . . . . . . . 5
3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . . 8
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 8
4.2. Initiating Connections Based on DNS Names . . . . . . . . 8
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9
5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9
5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9
5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . . 10
5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10
5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . . 12
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative references . . . . . . . . . . . . . . . . . . . 14
11.2. Informative references . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Simple Static Singly Homed End-Host . . . . . . . . . . . 5
3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . . 8
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 8
4.2. Initiating Connections Based on DNS Names . . . . . . . . 8
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9
5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9
5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9
5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . . 10
5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10
5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . . 12
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative references . . . . . . . . . . . . . . . . . . . 14
11.2. Informative references . . . . . . . . . . . . . . . . . . 15
This document specifies a new resource record (RR) for the Domain Name System (DNS) [RFC1034], and how to use it with the Host Identity Protocol (HIP) [RFC5201]. This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its HI), and the Domain Names of its rendezvous servers (RVSs) [RFC5204].
本文档指定了域名系统（DNS）[RFC1034]的新资源记录（RR），以及如何将其与主机标识协议（HIP）[RFC5201]一起使用。此RR允许HIP节点在DNS中存储其主机标识（HI，节点公钥-私钥对的公共组件）、主机标识标签（HIT，其HI的截断哈希）及其会合服务器（RVS）的域名[RFC5204]。
Currently, most of the Internet applications that need to communicate with a remote host first translate a domain name (often obtained via user input) into one or more IP address(es). This step occurs prior to communication with the remote host, and relies on a DNS lookup.
目前，大多数需要与远程主机通信的Internet应用程序首先将域名（通常通过用户输入获得）转换为一个或多个IP地址。此步骤发生在与远程主机通信之前，并依赖于DNS查找。
With HIP, IP addresses are intended to be used mostly for on-the-wire communication between end hosts, while most Upper Layer Protocols (ULP) and applications use HIs or HITs instead (ICMP might be an example of an ULP not using them). Consequently, we need a means to translate a domain name into an HI. Using the DNS for this translation is pretty straightforward: We define a new HIP resource record. Upon query by an application or ULP for a name to IP address lookup, the resolver would then additionally perform a name to HI lookup, and use it to construct the resulting HI to IP address mapping (which is internal to the HIP layer). The HIP layer uses the HI to IP address mapping to translate HIs and HITs into IP addresses and vice versa.
对于HIP，IP地址主要用于终端主机之间的有线通信，而大多数上层协议（ULP）和应用程序使用HIs或HITs（ICMP可能是ULP不使用HIs或HITs的一个示例）。因此，我们需要一种将域名转换为HI的方法。使用DNS进行此转换非常简单：我们定义了一个新的HIP资源记录。当应用程序或ULP查询名称到IP地址的查找时，解析器将另外执行名称到HI的查找，并使用它来构造生成的HI到IP地址映射（HIP层内部）。HIP层使用HI到IP地址映射将HI和HIT转换为IP地址，反之亦然。
The HIP Rendezvous Extension [RFC5204] allows a HIP node to be reached via the IP address(es) of a third party, the node's rendezvous server (RVS). An Initiator willing to establish a HIP association with a Responder served by an RVS would typically initiate a HIP exchange by sending an I1 towards the RVS IP address rather than towards the Responder IP address. Consequently, we need a means to find the name of a rendezvous server for a given host name.
HIP会合扩展[RFC5204]允许通过第三方（节点的会合服务器（RVS））的IP地址访问HIP节点。愿意与RVS服务的响应者建立HIP关联的发起人通常会通过向RVS IP地址而不是向响应者IP地址发送I1来发起HIP交换。因此，我们需要一种方法来查找给定主机名的集合服务器的名称。
This document introduces the new HIP DNS resource record to store the Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag (HIT) information.
本文档介绍了新的HIP DNS资源记录，用于存储会合服务器（RVS）、主机标识（HI）和主机标识标签（HIT）信息。
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]中所述进行解释。
In this section, we briefly introduce a number of usage scenarios where the DNS is useful with the Host Identity Protocol.
在本节中，我们将简要介绍一些DNS与主机标识协议配合使用的使用场景。
With HIP, most applications and ULPs are unaware of the IP addresses used to carry packets on the wire. Consequently, a HIP node could take advantage of having multiple IP addresses for fail-over, redundancy, mobility, or renumbering, in a manner that is transparent to most ULPs and applications (because they are bound to HIs; hence, they are agnostic to these IP address changes).
对于HIP，大多数应用程序和ULP不知道用于在线路上传输数据包的IP地址。因此，HIP节点可以利用具有多个IP地址的优势，以对大多数ULP和应用程序透明的方式进行故障切换、冗余、移动或重新编号（因为它们绑定到HIs；因此，它们对这些IP地址更改不可知）。
In these situations, for a node to be reachable by reference to its Fully Qualified Domain Name (FQDN), the following information should be stored in the DNS:
在这些情况下，要通过引用其完全限定域名（FQDN）来访问节点，DNS中应存储以下信息：
o A set of IP address(es) via A [RFC1035] and AAAA [RFC3596] RR sets (RRSets [RFC2181]).
o 通过[RFC1035]和AAAA[RFC3596]RR集合（RRSets[RFC2181]）的一组IP地址。
o A Host Identity (HI), Host Identity Tag (HIT), and possibly a set of rendezvous servers (RVS) through HIP RRs.
o 主机标识（HI）、主机标识标签（HIT），以及可能通过HIP RRs的一组集合服务器（RVS）。
When a HIP node wants to initiate communication with another HIP node, it first needs to perform a HIP base exchange to set up a HIP association towards its peer. Although such an exchange can be initiated opportunistically, i.e., without prior knowledge of the Responder's HI, by doing so both nodes knowingly risk man-in-the-middle attacks on the HIP exchange. To prevent these attacks, it is recommended that the Initiator first obtain the HI of the Responder, and then initiate the exchange. This can be done, for example, through manual configuration or DNS lookups. Hence, a new HIP RR is introduced.
当一个髋关节节点想要启动与另一个髋关节节点的通信时，它首先需要执行髋关节基础交换，以建立与对等节点的髋关节关联。尽管这样的交换可以机会主义地发起，即，在事先不知道响应者的HI的情况下，通过这样做，两个节点都有意地冒着中间人攻击髋部交换的风险。为了防止这些攻击，建议发起方首先获取响应方的HI，然后发起交换。例如，可以通过手动配置或DNS查找来完成此操作。因此，引入了一种新的HIP RR。
When a HIP node is frequently changing its IP address(es), the natural DNS latency for propagating changes may prevent it from publishing its new IP address(es) in the DNS. For solving this problem, the HIP Architecture [RFC4423] introduces rendezvous servers (RVSs) [RFC5204]. A HIP host uses a rendezvous server as a rendezvous point to maintain reachability with possible HIP initiators while moving [RFC5206]. Such a HIP node would publish in the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-to-date with its current set of IP addresses.
当HIP节点频繁更改其IP地址时，传播更改的自然DNS延迟可能会阻止其在DNS中发布新的IP地址。为了解决这个问题，HIP体系结构[RFC4423]引入了会合服务器（RVS）[RFC5204]。HIP主机使用会合服务器作为会合点，以在移动时保持与可能的HIP启动器的可达性[RFC5206]。这样的HIP节点将在DNS中发布HIP RR中的RVS域名，同时保持其RVS与其当前IP地址集保持最新。
When a HIP node wants to initiate a HIP exchange with a Responder, it will perform a number of DNS lookups. Depending on the type of implementation, the order in which those lookups will be issued may vary. For instance, implementations using HIT in APIs may typically first query for HIP resource records at the Responder FQDN, while
当HIP节点想要启动与响应者的HIP交换时，它将执行大量DNS查找。根据实现的类型，发出这些查找的顺序可能会有所不同。例如，在API中使用HIT的实现通常会首先在响应者FQDN处查询HIP资源记录，而
those using an IP address in APIs may typically first query for A and/or AAAA resource records.
在API中使用IP地址的用户通常会首先查询和/或AAAA资源记录。
In the following, we assume that the Initiator first queries for HIP resource records at the Responder FQDN.
在下文中，我们假设启动器首先在响应程序FQDN处查询HIP资源记录。
If the query for the HIP type was responded to with a DNS answer with RCODE=3 (Name Error), then the Responder's information is not present in the DNS and further queries for the same owner name SHOULD NOT be made.
如果对HIP类型的查询使用RCODE=3（名称错误）的DNS应答进行响应，则DNS中不存在响应者的信息，不应进一步查询相同的所有者名称。
In case the query for the HIP records returned a DNS answer with RCODE=0 (No Error) and an empty answer section, it means that no HIP information is available at the responder name. In such a case, if the Initiator has been configured with a policy to fallback to opportunistic HIP (initiating without knowing the Responder's HI) or plain IP, it would send out more queries for A and AAAA types at the Responder's FQDN.
如果对HIP记录的查询返回RCODE=0（无错误）的DNS应答和空应答部分，则表示在响应者名称处没有可用的HIP信息。在这种情况下，如果启动器配置了回退到机会主义HIP（在不知道响应者的HI的情况下启动）或普通IP的策略，则它将在响应者的FQDN处发送更多关于a和AAAA类型的查询。
Depending on the combinations of answers, the situations described in Section 3.1 and Section 3.2 can occur.
根据答案的组合，可能出现第3.1节和第3.2节中描述的情况。
Note that storing HIP RR information in the DNS at an FQDN that is assigned to a non-HIP node might have ill effects on its reachability by HIP nodes.
请注意，在分配给非HIP节点的FQDN处的DNS中存储HIP RR信息可能会对HIP节点的可达性产生不良影响。
A HIP node (R) with a single static network attachment, wishing to be reachable by reference to its FQDN (www.example.com), would store in the DNS, in addition to its IP address(es) (IP-R), its Host Identity (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record.
具有单个静态网络附件的HIP节点（R）希望通过引用其FQDN（www.example.com）来访问，除了HIP资源记录中的IP地址（IP-R）、主机标识（HI-R）和主机标识标签（HIT-R）之外，还将存储在DNS中。
An Initiator willing to associate with a node would typically issue the following queries:
愿意与节点关联的启动器通常会发出以下查询：
o QNAME=www.example.com, QTYPE=HIP
o QNAME=www.example.com，QTYPE=HIP
o (QCLASS=IN is assumed and omitted from the examples)
o （假设QCLASS=IN，并从示例中省略）
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer section, but no RVS.
它返回一个RCODE=0的DNS数据包和一个或多个HIP RRs，其中应答器的HIT和HI（例如HIT-R和HI-R）位于应答部分，但不返回RVS。
o QNAME=www.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
o QNAME=www.example.com，QTYPE=A QNAME=www.example.com，QTYPE=AAAA
Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs containing IP address(es) of the Responder (e.g., IP-R) in the answer section.
它返回RCODE=0的DNS数据包和一个或多个A或AAAA RRs，其中包含应答器（如IP-R）在应答部分的IP地址。
Caption: In the remainder of this document, for the sake of keeping diagrams simple and concise, several DNS queries and answers are represented as one single transaction, while in fact there are several queries and answers flowing back and forth, as described in the textual examples.
标题：在本文档的其余部分中，为了保持图表的简单和简洁，多个DNS查询和答案表示为一个事务，而事实上，如文本示例中所述，有多个查询和答案来回流动。
[HIP? A? ]
[www.example.com] +-----+
+-------------------------------->| |
| | DNS |
| +-------------------------------| |
| | [HIP? A? ] +-----+
| | [www.example.com]
| | [HIP HIT-R HI-R ]
| | [A IP-R ]
| v
+-----+ +-----+
| |--------------I1------------->| |
| I |<-------------R1--------------| R |
| |--------------I2------------->| |
| |<-------------R2--------------| |
+-----+ +-----+
[HIP? A? ]
[www.example.com] +-----+
+-------------------------------->| |
| | DNS |
| +-------------------------------| |
| | [HIP? A? ] +-----+
| | [www.example.com]
| | [HIP HIT-R HI-R ]
| | [A IP-R ]
| v
+-----+ +-----+
| |--------------I1------------->| |
| I |<-------------R1--------------| R |
| |--------------I2------------->| |
| |<-------------R2--------------| |
+-----+ +-----+
Static Singly Homed Host
静态单宿主主机
The Initiator would then send an I1 to the Responder's IP addresses (IP-R).
然后，发起者将向响应者的IP地址（IP-R）发送I1。
A mobile HIP node (R) wishing to be reachable by reference to its FQDN (www.example.com) would store in the DNS, possibly in addition to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R), and the domain name(s) of its rendezvous server(s) (e.g., rvs.example.com) in HIP resource record(s). The mobile HIP node also needs to notify its rendezvous servers of any change in its set of IP address(es).
希望通过引用其FQDN（www.example.com）来访问的移动HIP节点（R）将存储在DNS中，可能除了HIP资源记录中的IP地址（IP-R）、HI（HI-R）、HIT（HIT-R）和其会合服务器（例如rvs.example.com）的域名之外。移动HIP节点还需要将其IP地址集的任何更改通知其集合服务器。
An Initiator willing to associate with such a mobile node would typically issue the following queries:
愿意与这样的移动节点关联的发起方通常会发出以下查询：
o QNAME=www.example.com, QTYPE=HIP
o QNAME=www.example.com，QTYPE=HIP
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT, HI, and RVS domain name(s) (e.g., HIT-R, HI-R, and rvs.example.com) of the Responder in the answer section.
它返回一个RCODE=0的DNS数据包和一个或多个HIP RRs，其中包含应答器在应答部分的HIT、HI和RVS域名（例如HIT-R、HI-R和RVS.example.com）。
o QNAME=rvs.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
o QNAME=rvs.example.com，QTYPE=A QNAME=www.example.com，QTYPE=AAAA
Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs containing IP address(es) of the Responder's RVS (e.g., IP-RVS) in the answer section.
它返回RCODE=0的DNS数据包和一个或多个A或AAAA RRs，其中包含应答器RVS（例如IP-RVS）的IP地址（在应答部分）。
[HIP? ] [www.example.com]
[HIP？][www.example.com]
[A? ]
[rvs.example.com] +-----+
+----------------------------------------->| |
| | DNS |
| +----------------------------------------| |
| | [HIP? ] +-----+
| | [www.example.com ]
| | [HIP HIT-R HI-R rvs.example.com]
| |
| | [A? ]
| | [rvs.example.com]
| | [A IP-RVS ]
| |
| | +-----+
| | +------I1----->| RVS |-----I1------+
| | | +-----+ |
| | | |
| | | |
| v | v
+-----+ +-----+
| |<---------------R1------------| |
| I |----------------I2----------->| R |
| |<---------------R2------------| |
+-----+ +-----+
[A? ]
[rvs.example.com] +-----+
+----------------------------------------->| |
| | DNS |
| +----------------------------------------| |
| | [HIP? ] +-----+
| | [www.example.com ]
| | [HIP HIT-R HI-R rvs.example.com]
| |
| | [A? ]
| | [rvs.example.com]
| | [A IP-RVS ]
| |
| | +-----+
| | +------I1----->| RVS |-----I1------+
| | | +-----+ |
| | | |
| | | |
| v | v
+-----+ +-----+
| |<---------------R1------------| |
| I |----------------I2----------->| R |
| |<---------------R2------------| |
+-----+ +-----+
Mobile End-Host
移动终端主机
The Initiator would then send an I1 to the RVS IP address (IP-RVS). Following, the RVS will relay the I1 up to the mobile node's IP address (IP-R), which will complete the HIP exchange.
然后，启动器将向RVS IP地址（IP-RVS）发送I1。随后，RVS将I1中继至移动节点的IP地址（IP-R），从而完成HIP交换。
For any HIP node, its Host Identity (HI), the associated Host Identity Tag (HIT), and the FQDN of its possible RVSs can be stored in a DNS HIP RR. Any conforming implementation may store a Host Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP RDATA format. HI and HIT are defined in Section 3 of the HIP specification [RFC5201].
对于任何HIP节点，其主机标识（HI）、关联的主机标识标记（HIT）及其可能RVS的FQDN都可以存储在DNS HIP RR中。任何符合要求的实现都可以以DNS HIP RDATA格式存储主机标识（HI）及其关联的主机标识标签（HIT）。HI和HIT在HIP规范[RFC5201]第3节中有定义。
Upon return of a HIP RR, a host MUST always calculate the HI-derivative HIT to be used in the HIP exchange, as specified in Section 3 of the HIP specification [RFC5201], while the HIT possibly embedded along SHOULD only be used as an optimization (e.g., table lookup).
在返回HIP RR时，主机必须始终计算HIP交换中使用的HI导数命中，如HIP规范[RFC5201]第3节中的规定，而可能嵌入的命中只能用作优化（例如，查表）。
The HIP resource record may also contain one or more domain name(s) of rendezvous server(s) towards which HIP I1 packets might be sent to trigger the establishment of an association with the entity named by this resource record [RFC5204].
HIP资源记录还可包含会合服务器的一个或多个域名，HIP I1数据包可发送至该会合服务器，以触发与该资源记录命名的实体建立关联[RFC5204]。
The rendezvous server field of the HIP resource record stored at a given owner name MAY include the owner name itself. A semantically equivalent situation occurs if no rendezvous server is present in the HIP resource record stored at that owner name. Such situations occur in two cases:
以给定所有者名称存储的HIP资源记录的集合服务器字段可能包括所有者名称本身。如果以该所有者名称存储的HIP资源记录中不存在集合服务器，则会出现语义等效的情况。这种情况发生在两种情况下：
o The host is mobile, and the A and/or AAAA resource record(s) stored at its host name contain the IP address(es) of its rendezvous server rather than its own one.
o 主机是移动的，存储在其主机名中的A和/或AAAA资源记录包含其会合服务器的IP地址，而不是其自己的IP地址。
o The host is stationary, and can be reached directly at the IP address(es) contained in the A and/or AAAA resource record(s) stored at its host name. This is a degenerated case of rendezvous service where the host somewhat acts as a rendezvous server for itself.
o 主机是固定的，可以通过存储在主机名处的A和/或AAAA资源记录中包含的IP地址直接访问该主机。这是会合服务的退化情况，主机在某种程度上充当自身的会合服务器。
An RVS receiving such an I1 would then relay it to the appropriate Responder (the owner of the I1 receiver HIT). The Responder will then complete the exchange with the Initiator, typically without ongoing help from the RVS.
接收到这种I1的RVS随后会将其转发给相应的响应者（I1接收器命中的所有者）。然后，响应者将完成与发起人的交换，通常无需RVS的持续帮助。
On a HIP node, a Host Identity Protocol exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity and the DNS lookup returns HIP resource records.
在HIP节点上，每当ULP尝试与实体通信且DNS查找返回HIP资源记录时，应启动主机标识协议交换。
The RDATA for a HIP RR consists of a public key algorithm type, the HIT length, a HIT, a public key, and optionally one or more rendezvous server(s).
HIP RR的RDATA由公钥算法类型、命中长度、命中、公钥和可选的一个或多个集合服务器组成。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT length | PK algorithm | PK length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIT ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+ +
| Public Key |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Rendezvous Servers ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT length | PK algorithm | PK length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIT ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+ +
| Public Key |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Rendezvous Servers ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+
The HIT length, PK algorithm, PK length, HIT, and Public Key fields are REQUIRED. The Rendezvous Servers field is OPTIONAL.
命中长度、PK算法、PK长度、命中和公钥字段是必需的。“集合服务器”字段是可选的。
The HIT length indicates the length in bytes of the HIT field. This is an 8-bit unsigned integer.
命中长度表示命中字段的字节长度。这是一个8位无符号整数。
The PK algorithm field indicates the public key cryptographic algorithm and the implied public key field format. This is an 8-bit unsigned integer. This document reuses the values defined for the 'algorithm type' of the IPSECKEY RR [RFC4025].
PK算法字段表示公钥加密算法和隐含公钥字段格式。这是一个8位无符号整数。本文档重用为IPSECKEY RR[RFC4025]的“算法类型”定义的值。
Presently defined values are listed in Section 9 for reference.
第9节列出了当前定义的值，以供参考。
The PK length indicates the length in bytes of the Public key field. This is a 16-bit unsigned integer in network byte order.
PK长度表示公钥字段的字节长度。这是网络字节顺序的16位无符号整数。
The HIT is stored as a binary value in network byte order.
命中以网络字节顺序存储为二进制值。
Both of the public key types defined in this document (RSA and DSA) reuse the public key formats defined for the IPSECKEY RR [RFC4025].
本文档中定义的两种公钥类型（RSA和DSA）都重用了为IPSECKEY RR[RFC4025]定义的公钥格式。
The DSA key format is defined in RFC 2536 [RFC2536].
DSA密钥格式在RFC 2536[RFC2536]中定义。
The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] specification.
RSA密钥格式在RFC 3110[RFC3110]中定义，RSA密钥大小限制（4096位）在IPSECKEY RR[RFC4025]规范中放宽。
The Rendezvous Servers field indicates one or more variable length wire-encoded domain names of rendezvous server(s), as described in Section 3.3 of RFC 1035 [RFC1035]. The wire-encoded format is self-describing, so the length is implicit. The domain names MUST NOT be compressed. The rendezvous server(s) are listed in order of preference (i.e., first rendezvous server(s) are preferred), defining an implicit order amongst rendezvous servers of a single RR. When multiple HIP RRs are present at the same owner name, this implicit order of rendezvous servers within an RR MUST NOT be used to infer a preference order between rendezvous servers stored in different RRs.
如RFC 1035[RFC1035]第3.3节所述，会合服务器字段表示会合服务器的一个或多个可变长度有线编码域名。导线编码格式是自描述的，因此长度是隐式的。不得压缩域名。集合服务器按优先顺序列出（即，首选第一个集合服务器），定义单个RR的集合服务器之间的隐式顺序。当多个HIP RRs以相同的所有者名称存在时，RR中会合服务器的隐式顺序不得用于推断不同RRs中存储的会合服务器之间的首选顺序。
This section specifies the representation of the HIP RR in a zone master file.
本节指定HIP RR在分区主文件中的表示形式。
The HIT length field is not represented, as it is implicitly known thanks to the HIT field representation.
未表示命中长度字段，因为由于命中字段表示，它是隐式已知的。
The PK algorithm field is represented as unsigned integers.
PK算法字段表示为无符号整数。
The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a. hex or hexadecimal) of the HIT. The encoding MUST NOT contain whitespaces to distinguish it from the public key field.
命中字段表示为命中的Base16编码[RFC4648]（也称十六进制或十六进制）。编码不能包含空格，以将其与公钥字段区分开来。
The Public Key field is represented as the Base64 encoding [RFC4648] of the public key. The encoding MUST NOT contain whitespace(s) to distinguish it from the Rendezvous Servers field.
公钥字段表示为公钥的Base64编码[RFC4648]。编码不能包含空格，以将其与“集合服务器”字段区分开来。
The PK length field is not represented, as it is implicitly known thanks to the Public key field representation containing no whitespaces.
PK长度字段没有表示，因为公钥字段表示不包含空格，所以它是隐式表示的。
The Rendezvous Servers field is represented by one or more domain name(s) separated by whitespace(s).
“集合服务器”字段由一个或多个域名表示，域名之间用空格分隔。
The complete representation of the HPIHI record is:
HPIHI记录的完整表示为：
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key rendezvous-server[1] ... rendezvous-server[n] )
HIP中（pk算法base16编码hit base64编码公钥集合服务器[1]…集合服务器[n]）
When no RVSs are present, the representation of the HPIHI record is:
当不存在RVS时，HPIHI记录的表示为：
IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key )
HIP中（pk算法base16编码hit base64编码公钥）
In the examples below, the public key field containing no whitespace is wrapped since it does not fit in a single line of this document.
在下面的示例中，不包含空格的公钥字段被包装，因为它不适合本文档的一行。
Example of a node with HI and HIT but no RVS:
具有HI和HIT但没有RVS的节点示例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D )
www.example.com。HIP（2 200100107B1A74DF3639CC39F1D578 AWEABDXYHNUSUTC5EMZXTS9LBPCIKOFH8CIVM4P 9+LrV4e19WzK00+CI6ZBCQTDWSUKBWIY87UOJTWKUS7LBU+Upr1gsNrut79ryra+bSRGQ B1SLIMA8YVJ7KWZG7JNERNWXZ48AWKSKMDHAVDHAP4BCELRTI3RMXD5D）
Example of a node with a HI, HIT, and one RVS:
具有HI、HIT和一个RVS的节点示例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs.example.com. )
www.example.com。HIP（2 200100107B1A74DF3639CC39F1D578 AWEABDXYHNUSUTC5EMZXTS9LBPCIKOFH8CIVM4P 9+LrV4e19WzK00+CI6ZBCQTWTWSUKBWIY87UOJTWKUS7LBU+Upr1gsNrut79ryra+bSRGQ B1SLIMA8YVJ7KWZG7JNERNWXZ48AWKSKMDHAVDHAP4BCELRTI3RMXD5D rvs.example.com）
Example of a node with a HI, HIT, and two RVSs:
具有HI、HIT和两个RVS的节点示例：
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs1.example.com. rvs2.example.com. )
www.example.com。HIP中（2 200100107B1A74DF3639CC39F1D578 AWEABDXYHNUSUTC5EMZXTS9LBPCIKOFH8CIVM4P 9+LrV4e19WzK00+CI6ZBCQTWTWSUKBWIY87UOJTWKUS7LBU+Upr1gsNrut79ryra+bSRGQ B1SLIMA8YVJ7KWZG7JNERNWXZ48AWKSKMDHAVDHAP4BCELRTI3RMXF5D rvs1.example.com.rvs2.example.com）
This section contains a description of the known threats involved with the usage of the HIP DNS Extension.
本节包含使用HIP DNS扩展所涉及的已知威胁的描述。
In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS Extension allows for the provision of two HIP nodes with the public keying material (HI) of their peer. These HIs will be subsequently used in a key exchange between the peers. Hence, the HIP DNS Extension introduces the same kind of threats that IPSECKEY does, plus threats caused by the possibility given to a HIP node to initiate or accept a HIP exchange using "opportunistic" or "unpublished Initiator HI" modes.
以类似于IPSECKEY RR[RFC4025]的方式，HIP DNS扩展允许提供两个HIP节点及其对等节点的公钥材料（HI）。这些HIs随后将用于对等方之间的密钥交换。因此，HIP DNS扩展引入了与IPSECKEY相同的威胁，加上HIP节点使用“机会主义”或“未发布的启动器HI”模式发起或接受HIP交换的可能性所造成的威胁。
A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure channel ensuring data integrity and authenticity of the RRs. DNSSEC [RFC4033] [RFC4034] [RFC4035] provides such a secure channel. However, it should be emphasized that DNSSEC only offers data integrity and authenticity guarantees to the channel between the DNS server publishing a zone and the HIP node. DNSSEC does not ensure that the entity publishing the zone is trusted. Therefore, the RRSIG signature of the HIP RRSet MUST NOT be misinterpreted as a certificate binding the HI and/or the HIT to the owner name.
HIP节点应通过安全通道从受信任方获取HIP RRs，确保RRs的数据完整性和真实性。DNSSEC[RFC4033][RFC4034][RFC4035]提供了这样一个安全通道。但是，应该强调的是，DNSSEC仅为发布区域的DNS服务器和HIP节点之间的通道提供数据完整性和真实性保证。DNSSEC不确保发布区域的实体受信任。因此，不得将HIP RRSet的RRSIG签名误解为将HI和/或HIT绑定到所有者名称的证书。
In the absence of a proper secure channel, both parties are vulnerable to MitM and DoS attacks, and unrelated parties might be subject to DoS attacks as well. These threats are described in the following sections.
在没有适当的安全通道的情况下，双方都容易受到MitM和DoS攻击，不相关的双方也可能受到DoS攻击。这些威胁将在以下章节中描述。
The HIP RR contains public keying material in the form of the named peer's public key (the HI) and its secure hash (the HIT). Both of these are not sensitive to attacks where an adversary gains knowledge of them. However, an attacker that is able to mount an active attack on the DNS, i.e., tampers with this HIP RR (e.g., using DNS spoofing), is able to mount Man-in-the-Middle attacks on the cryptographic core of the eventual HIP exchange (Responder's HIP RR rewritten by the attacker).
HIP RR包含以命名对等方的公钥（HI）及其安全散列（HIT）形式存在的公钥材料。这两种方法对敌人知道的攻击都不敏感。但是，能够在DNS上发起主动攻击的攻击者，即篡改此HIP RR（例如，使用DNS欺骗），能够在最终HIP交换的加密核心上发起中间人攻击（响应者的HIP RR由攻击者重写）。
The HIP RR may contain a rendezvous server domain name resolved into a destination IP address where the named peer is reachable by an I1, as per the HIP Rendezvous Extension [RFC5204]. Thus, an attacker able to tamper with this RR is able to redirect I1 packets sent to the named peer to a chosen IP address for DoS or MitM attacks. Note that this kind of attack is not specific to HIP and exists independently of whether or not HIP and the HIP RR are used. Such an attacker might tamper with A and AAAA RRs as well.
The HIP RR may contain a rendezvous server domain name resolved into a destination IP address where the named peer is reachable by an I1, as per the HIP Rendezvous Extension [RFC5204]. Thus, an attacker able to tamper with this RR is able to redirect I1 packets sent to the named peer to a chosen IP address for DoS or MitM attacks. Note that this kind of attack is not specific to HIP and exists independently of whether or not HIP and the HIP RR are used. Such an attacker might tamper with A and AAAA RRs as well.translate error, please retry
An attacker might obviously use these two attacks in conjunction: It will replace the Responder's HI and RVS IP address by its own in a spoofed DNS packet sent to the Initiator HI, then redirect all exchanged packets to him and mount a MitM on HIP. In this case, HIP won't provide confidentiality nor Initiator HI protection from eavesdroppers.
攻击者显然可能同时使用这两种攻击：它将在发送给启动器HI的伪造DNS数据包中用自己的IP地址替换响应者的HI和RVS IP地址，然后将所有交换的数据包重定向给他，并在HIP上安装MitM。在这种情况下，HIP既不提供机密性，也不提供防止窃听者的保护。
As with many cryptographic algorithms, some secure hashes (e.g., SHA1, used by HIP to generate a HIT from an HI) eventually become insecure, because an exploit has been found in which an attacker with reasonable computation power breaks one of the security features of the hash (e.g., its supposed collision resistance). This is why a HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from the DNS, but SHOULD rather use HI-based authentication.
与许多加密算法一样，一些安全散列（例如SHA1，HIP用于从HI生成命中）最终变得不安全，因为发现了一个漏洞，具有合理计算能力的攻击者破坏了散列的一个安全特性（例如，其假定的抗冲突性）。这就是为什么HIP端节点实现不应仅基于从DNS检索到的HIT对其HIP对等方进行身份验证，而应使用基于HI的身份验证。
In the absence of DNSSEC, the HIP RR is subject to the threats described in RFC 3833 [RFC3833].
在没有DNSSEC的情况下，HIP RR受到RFC 3833[RFC3833]中所述的威胁。
IANA has allocated one new RR type code (55) for the HIP RR from the standard RR type space.
IANA已从标准RR类型空间为HIP RR分配了一个新的RR类型代码（55）。
IANA does not need to open a new registry for public key algorithms of the HIP RR because the HIP RR reuses "algorithms types" defined for the IPSECKEY RR [RFC4025]. Presently defined values are shown here for reference only:
IANA不需要为HIP RR的公钥算法打开新的注册表，因为HIP RR重用为IPSECKEY RR定义的“算法类型”[RFC4025]。此处显示的当前定义值仅供参考：
0 is reserved
0是保留的
1 is DSA
1是DSA
2 is RSA
2是RSA
In the future, if a new algorithm is to be used for the HIP RR, a new algorithm type and corresponding public key encoding should be defined for the IPSECKEY RR. The HIP RR should reuse both the same algorithm type and the same corresponding public key format as the IPSECKEY RR.
将来，如果HIP RR使用新算法，则应为IPSECKEY RR定义新算法类型和相应的公钥编码。HIP RR应重复使用与IPSECKEY RR相同的算法类型和相同的相应公钥格式。
As usual in the IETF, this document is the result of a collaboration between many people. The authors would like to thank the author (Michael Richardson), contributors, and reviewers of the IPSECKEY RR [RFC4025] specification, after which this document was framed. The authors would also like to thank the following people, who have provided thoughtful and helpful discussions and/or suggestions, that have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro. Some parts of this document stem from the HIP specification [RFC5201].
与IETF中的通常情况一样，本文档是许多人协作的结果。作者要感谢IPSECKEY RR[RFC4025]规范的作者（Michael Richardson）、贡献者和评审者，在此之后，本文档被框架化。作者还要感谢以下人士，他们提供了有助于改进本文件的深思熟虑和有益的讨论和/或建议：杰夫·阿伦霍尔茨、罗布·奥斯汀、汉努·弗林克、奥拉弗尔·古德蒙德森、汤姆·亨德森、彼得·科赫、奥拉夫·科尔克曼、米卡·科姆、安德鲁·麦格雷戈、埃里克·诺德马克和加布里埃尔·黑山。本文件的某些部分源自HIP规范[RFC5201]。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]Richardson，M.，“在DNS中存储IPsec密钥材料的方法”，RFC 4025，2005年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，Ed.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，RFC 52042008年4月。
[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月。
[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月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Henderson，T.，Ed.“终端主机移动性和主机身份协议的多宿”，RFC 5206，2008年4月。
Authors' Addresses
作者地址
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
佩卡·尼坎德·爱立信研究实验室JORVAS FIN-02420芬兰
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
Julien Laganier DoCoMo通信实验室欧洲有限公司兰德斯伯格大街312慕尼黑80687德国
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.