Network Working Group P. Nikander
Request for Comments: 4843 Ericsson Research Nomadic Lab
Category: Experimental J. Laganier
DoCoMo Euro-Labs
F. Dupont
CELAR
April 2007
Network Working Group P. Nikander
Request for Comments: 4843 Ericsson Research Nomadic Lab
Category: Experimental J. Laganier
DoCoMo Euro-Labs
F. Dupont
CELAR
April 2007
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
覆盖可路由加密哈希标识符（RAYD）的IPv6前缀
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.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address-like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.
本文档介绍了覆盖可路由加密散列标识符（RAYD），作为IPv6地址类标识符的一个新的实验类。这些标识符旨在用作应用程序和应用程序编程接口（API）处的端点标识符，而不是用作IP层处网络位置的标识符，即定位器。它们被设计为作为应用层实体出现在现有的IPv6 API中，但不应出现在实际的IPv6头中。为了使它们更像普通的IPv6地址，它们应该可以在覆盖层上路由。因此，虽然从IPv6层的角度来看，它们被视为不可路由地址，但所有现有IPv6应用程序都希望能够以与当前IPv6地址兼容的方式使用它们。
This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus.
本文档要求IANA从IPv6寻址空间中为覆盖可路由加密哈希标识符分配一个临时前缀。默认情况下，前缀将在2014年返回IANA，继续使用需要IETF协商一致。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 4
1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5
3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 6
3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 6
4. Collision Considerations . . . . . . . . . . . . . . . . . . . 7
5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 4
1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5
3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 6
3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 6
4. Collision Considerations . . . . . . . . . . . . . . . . . . . 7
5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID), a new class of IP address-like identifiers. These identifiers are intended to be globally unique in a statistical sense (see Section 4), non-routable at the IP layer, and routable at some overlay layer. The identifiers are securely bound, via a secure hash function, to the concatenation of an input bitstring and a context tag. Typically, but not necessarily, the input bitstring will include a suitably encoded public cryptographic key.
本文档介绍了覆盖可路由加密散列标识符（RAYD），这是一种新的IP地址类标识符。这些标识符在统计意义上是全局唯一的（见第4节），在IP层不可路由，在某些覆盖层可路由。标识符通过安全哈希函数安全地绑定到输入位字符串和上下文标记的串联。通常，但不一定，输入比特串将包括适当编码的公钥。
These identifiers are expected to be used at the existing IPv6 Application Programming Interfaces (API) and application protocols between consenting hosts. They may be defined and used in different contexts, suitable for different overlay protocols. Examples of these include Host Identity Tags (HIT) in the Host Identity Protocol (HIP) [HIP-BASE] and Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension [PRIVACYTEXT].
这些标识符预计将用于同意主机之间的现有IPv6应用程序编程接口（API）和应用程序协议。它们可以在不同的上下文中定义和使用，适用于不同的覆盖协议。这些示例包括主机标识协议（HIP）[HIP-BASE]中的主机标识标签（HIT）和用于移动IPv6隐私扩展[PRIVACYTEXT]的临时移动标识符（TMI）。
As these identifiers are expected to be used along with IPv6 addresses at both applications and APIs, co-ordination is desired to make sure that an ORCHID is not inappropriately taken for a vanilla IPv6 address and vice versa. In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer.
由于这些标识符预计将在应用程序和API中与IPv6地址一起使用，因此需要进行协调，以确保不会不适当地将兰花用作普通IPv6地址，反之亦然。在实践中，为兰花分配一个单独的前缀似乎就足够了，使其与上层的IPv6地址兼容，同时使其在IP层的使用变得微不足道。
While being technically possible to use ORCHIDs between consenting hosts without any co-ordination with the IETF and the IANA, the authors would consider such practice potentially dangerous. A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other new purpose. That would lead to partial balkanisation of the Internet, similar to what has happened as a result of historical hijackings of non-RFC 1918 [RFC1918] IPv4 addresses for private use.
虽然在技术上有可能在同意的主机之间使用兰花而不与IETF和IANA进行协调，但是作者认为这种做法可能是危险的。如果IETF社区后来决定将兰花前缀用于某些不同的目的，那么就会意识到一种特殊的危险。在这种情况下，出于实际目的，使用兰花前缀的主机将无法将前缀用于其他新用途。这将导致互联网的局部分裂，类似于历史上劫持非RFC1918[RFC1918]IPv4地址供私人使用所造成的情况。
The whole need for the proposed allocation grows from the desire to be able to use ORCHIDs with existing applications and APIs. This desire leads to the potential conflict, mentioned above. Resolving the conflict requires the proposed allocation.
提议的分配的全部需求源于能够在现有应用程序和API中使用兰花的愿望。这一愿望导致上述潜在冲突。解决冲突需要建议的分配。
One can argue that the desire to use these kinds of identifiers via existing APIs is architecturally wrong, and there is some truth in that argument. Indeed, it would be more desirable to introduce a new API and update all applications to use identifiers, rather than locators, via that new API. That is exactly what we expect to happen in the long run.
有人可能会说，希望通过现有的API使用这些类型的标识符在架构上是错误的，这一观点是正确的。事实上，更可取的做法是引入一个新的API，并通过该新API更新所有应用程序以使用标识符，而不是定位器。从长远来看，这正是我们所期望的。
However, given the current state of the Internet, we do not consider it viable to introduce any changes that, at once, require applications to be rewritten and host stacks to be updated. Rather than that, we believe in piece-wise architectural changes that require only one of the existing assets to be touched. ORCHIDs are designed to address this situation: to allow people to experiment with protocol stack extensions, such as secure overlay routing, HIP, or Mobile IP privacy extensions, without requiring them to update their applications. The goal is to facilitate large-scale experiments with minimum user effort.
然而，考虑到因特网的当前状态，我们不认为引入任何修改，即需要修改应用程序和更新主机堆栈是可行的。与此相反，我们相信逐段的体系结构更改，只需要触及现有资产中的一项。兰花旨在解决这种情况：允许人们试验协议栈扩展，如安全覆盖路由、HIP或移动IP隐私扩展，而无需更新应用程序。目标是以最少的用户努力促进大规模实验。
For example, there already exists, at the time of this writing, HIP implementations that run fully in user space, using the operating system to divert a certain part of the IPv6 address space to a user level daemon for HIP processing. In practical terms, these implementations are already using a certain IPv6 prefix for differentiating HIP identifiers from IPv6 addresses, allowing them both to be used by the existing applications via the existing APIs.
例如，在撰写本文时，已经存在完全在用户空间中运行的HIP实现，使用操作系统将IPv6地址空间的某一部分转移到用户级守护进程以进行HIP处理。实际上，这些实现已经在使用某个IPv6前缀来区分HIP标识符和IPv6地址，从而允许现有应用程序通过现有API使用它们。
This document argues for allocating an experimental prefix for such purposes, thereby paving the way for large-scale experiments with cryptographic identifiers without the dangers caused by address-space hijacking.
本文件主张为此目的分配一个实验性前缀，从而为大规模密码标识符实验铺平道路，而不存在地址空间劫持所造成的危险。
ORCHIDs are designed to have the following properties:
兰花具有以下特性：
o Statistical uniqueness; also see Section 4
o 统计唯一性；另见第4节
o Secure binding to the input parameters used in their generation (i.e., the context identifier and a bitstring).
o 安全绑定到生成时使用的输入参数（即上下文标识符和位字符串）。
o Aggregation under a single IPv6 prefix. Note that this is only needed due to the co-ordination need as indicated above. Without such co-ordination need, the ORCHID namespace could potentially be completely flat.
o 聚合在单个IPv6前缀下。请注意，这仅是由于上述协调需要而需要的。如果没有这种协调需求，兰花名称空间可能会完全扁平化。
o Non-routability at the IP layer, by design.
o 根据设计，IP层的非路由性。
o Routability at some overlay layer, making them, from an application point of view, semantically similar to IPv6 addresses.
o 某些覆盖层的可路由性，从应用程序的角度来看，使它们在语义上类似于IPv6地址。
As mentioned above, ORCHIDs are intended to be generated and used in different contexts, as suitable for different mechanisms and protocols. The context identifier is meant to be used to differentiate between the different contexts; see Section 4 for a discussion of the related API and kernel level implementation issues, and Section 5 for the design choices explaining why the context identifiers are used.
如上所述，兰花旨在在不同的环境中生成和使用，以适合不同的机制和协议。上下文标识符用于区分不同的上下文；有关相关API和内核级实现问题的讨论，请参见第4节；有关解释为何使用上下文标识符的设计选择，请参见第5节。
Examples of identifiers and protocols that are expected to adopt the ORCHID format include Host Identity Tags (HIT) in the Host Identity Protocol [HIP-BASE] and the Temporary Mobile Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6 [PRIVACYTEXT]. The format is designed to be extensible to allow other experimental proposals to share the same namespace.
预期采用兰花格式的标识符和协议的示例包括主机标识协议[HIP-BASE]中的主机标识标签（HIT）和移动IPv6的简单隐私扩展[PRIVACYTEXT]中的临时移动标识符（TMI）。该格式设计为可扩展的，以允许其他实验方案共享同一名称空间。
This document requests IANA to allocate an experimental prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers.
本文档要求IANA从IPv6寻址空间中为覆盖可路由加密哈希标识符分配一个实验前缀。
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]中所述进行解释。
An ORCHID is generated using the algorithm below. The algorithm takes a bitstring and a context identifier as input and produces an ORCHID as output.
使用下面的算法生成兰花。该算法将一个位字符串和一个上下文标识符作为输入，并生成一个兰花作为输出。
Input := any bitstring
Hash Input := Context ID | Input
Hash := Hash_function( Hash Input )
ORCHID := Prefix | Encode_100( Hash )
Input := any bitstring
Hash Input := Context ID | Input
Hash := Hash_function( Hash Input )
ORCHID := Prefix | Encode_100( Hash )
where:
哪里：
| : Denotes concatenation of bitstrings
|：表示位字符串的串联
Input : A bitstring that is unique or statistically unique within a given context. The bitstring is intended to be associated with the to-be-created ORCHID in the given context.
输入：在给定上下文中唯一或统计上唯一的位字符串。位字符串旨在与给定上下文中要创建的对象关联。
Context ID : A randomly generated value defining the expected usage context for the particular ORCHID and the hash function to be used for generation of ORCHIDs in this context. These values are allocated out of the namespace introduced for CGA Type Tags; see RFC 3972 and http://www.iana.org/assignments/cga-message-types.
上下文ID：一个随机生成的值，用于定义特定兰花的预期使用上下文以及在此上下文中用于生成兰花的哈希函数。这些值是从为CGA类型标记引入的名称空间中分配的；见RFC 3972和http://www.iana.org/assignments/cga-message-types.
Hash_function : The one-way hash function (i.e., hash function with pre-image resistance and second pre-image resistance) to be used according to the document defining the context usage identified by the Context ID. For example, the current version of the HIP specification defines SHA1 [RFC3174] as the hash function to be used to generate ORCHIDs used in the HIP protocol [HIP-BASE].
Hash_函数：根据定义上下文ID标识的上下文用法的文档使用的单向哈希函数（即，具有图像前阻力和第二图像前阻力的哈希函数）。例如，HIP规范的当前版本定义了SHA1[RFC3174]作为用于生成HIP协议[HIP-BASE]中使用的兰花的哈希函数。
Encode_100( ) : An extraction function in which output is obtained by extracting the middle 100-bit-long bitstring from the argument bitstring.
Encode_100（）：一种提取函数，在该函数中，通过从参数位字符串中提取中间100位长的位字符串来获得输出。
Prefix : A constant 28-bit-long bitstring value (2001:10::/28).
前缀：恒定的28位长的位字符串值（2001:10:：/28）。
To form an ORCHID, two pieces of input data are needed. The first piece can be any bitstring, but is typically expected to contain a public cryptographic key and some other data. The second piece is a
要形成一个兰花，需要两个输入数据。第一部分可以是任何位字符串，但通常需要包含公钥和一些其他数据。第二件是一个
context identifier, which is a 128-bit-long datum, allocated as specified in Section 7. Each specific experiment (such as HIP HITs or MIP6 TMIs) is expected to allocate their own, specific context identifier.
上下文标识符，是一个128位长的数据，按照第7节的规定分配。每个特定实验（如HIP HITs或MIP6 TMI）都需要分配自己的特定上下文标识符。
The input bitstring and context identifier are concatenated to form an input datum, which is then fed to the cryptographic hash function to be used according to the document defining the context usage identified by the Context ID. The result of the hash function is processed by an encoding function, resulting in a 100-bit-long value. This value is prepended with the 28-bit ORCHID prefix. The result is the ORCHID, a 128-bit-long bitstring that can be used at the IPv6 APIs in hosts participating to the particular experiment.
将输入位字符串和上下文标识符连接起来以形成一个输入数据，然后将其输入到加密哈希函数，以便根据定义上下文ID标识的上下文用法的文档使用。哈希函数的结果由一个编码函数处理，产生一个100位长的值。此值前面带有28位兰花前缀。结果就是兰花，一种128位长的比特字符串，可以在参与特定实验的主机的IPv6 API中使用。
The ORCHID prefix is allocated under the IPv6 global unicast address block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast addresses. However, it should be noted that ORCHIDs do not conform with the IPv6 global unicast address format defined in Section 2.5.4 of [RFC4291] since they do not have a 64-bit Interface ID formatted as described in Section 2.5.1. of [RFC4291].
兰花前缀在IPv6全局单播地址块下分配。因此，兰花与IPv6全局单播地址无法区分。但是，应注意，兰花不符合[RFC4291]第2.5.4节中定义的IPv6全局单播地址格式，因为它们没有第2.5.1节中所述的64位接口ID格式。属于[RFC4291]。
ORCHIDs are designed to serve as location independent endpoint-identifiers rather than IP-layer locators. Therefore, routers MAY be configured not to forward any packets containing an ORCHID as a source or a destination address. If the destination address is an ORCHID but the source address is a valid unicast source address, routers MAY be configured to generate an ICMP Destination Unreachable, Administratively Prohibited message.
兰花被设计成与位置无关的端点标识符，而不是IP层定位器。因此，路由器可被配置为不转发包含兰花作为源地址或目的地址的任何分组。如果目标地址是兰花，但源地址是有效的单播源地址，则路由器可配置为生成ICMP目标不可到达、管理禁止的消息。
Due to the experimental nature of ORCHIDs, router software MUST NOT include any special handling code for ORCHIDs. In other words, the non-routability property of ORCHIDs, if implemented, MUST be implemented via configuration and NOT by hardwired software code. At this time, it is RECOMMENDED that the default router configuration not handle ORCHIDs in any special way. In other words, there is no need to touch existing or new routers due to this experiment. If such a reason should later appear, for example, due to a faulty implementation leaking ORCHIDs to the IP layer, the prefix can be and should be blocked by a simple configuration rule.
由于兰花的实验性质，路由器软件不得包含任何兰花的特殊处理代码。换句话说，如果实现了兰花的非路由性属性，则必须通过配置而不是硬连线软件代码来实现。此时，建议默认路由器配置不要以任何特殊方式处理兰花。换句话说，由于这个实验，不需要接触现有的或新的路由器。如果稍后出现这样的原因，例如，由于错误的实现将兰花泄漏到IP层，那么前缀可以并且应该被简单的配置规则阻止。
As mentioned multiple times, ORCHIDs are designed to be non-routable at the IP layer. However, there are multiple ongoing research efforts for creating various overlay routing and resolution mechanisms for flat identifiers. For example, the Host Identity
正如多次提到的，兰花被设计为在IP层不可路由。然而，目前正在进行多项研究工作，为平面标识符创建各种覆盖路由和解析机制。例如，主机标识
Indirection Infrastructure (Hi3) [Hi3] and Node Identity Internetworking Architecture (NodeID) [NodeID] proposals, outline ways for using a Distributed Hash Table to forward HIP packets based on the Host Identity Tag.
间接寻址基础设施（Hi3）[Hi3]和节点标识互连体系结构（NodeID）[NodeID]提案概述了使用分布式哈希表转发基于主机标识标记的HIP数据包的方法。
What is common to the various research proposals is that they create a new kind of resolution or routing infrastructure on top of the existing Internet routing structure. In practical terms, they allow delivery of packets based on flat, non-routable identifiers, utilising information stored in a distributed database. Usually, the database used is based on Distributed Hash Tables. This effectively creates a new routing network on top of the existing IP-based routing network, capable of routing packets that are not addressed by IP addresses but some other kind of identifiers.
各种研究提案的共同点是，它们在现有互联网路由结构的基础上创建了一种新的解决方案或路由基础设施。实际上，它们允许利用存储在分布式数据库中的信息，基于平面的、不可路由的标识符传递数据包。通常，所使用的数据库基于分布式哈希表。这有效地在现有基于IP的路由网络的基础上创建了一个新的路由网络，该网络能够路由不是由IP地址而是某些其他类型的标识符寻址的数据包。
Typical benefits from overlay routing include location independence, more scalable multicast, anycast, and multihoming support than in IP, and better DoS resistance than in the vanilla Internet. The main drawback is typically an order of magnitude of slower performance, caused by an easily largish number of extra look-up or forwarding steps needed. Consequently, in most practical cases, the overlay routing system is used only during initial protocol state set-up (cf. TCP handshake), after which the communicating endpoints exchange packets directly with IP, bypassing the overlay network.
覆盖路由的典型优势包括位置独立性、比IP更具可扩展性的多播、选播和多宿主支持，以及比普通互联网更好的抗DoS能力。主要缺点通常是性能降低了一个数量级，这是由于需要大量额外的查找或转发步骤造成的。因此，在大多数实际情况下，覆盖路由系统仅在初始协议状态设置（参见TCP握手）期间使用，在此之后，通信端点绕过覆盖网络直接与IP交换数据包。
The net result of the typical overlay routing approaches is a communication service whose basic functionality is comparable to that provided by classical IP but provides considerably better resilience that vanilla IP in dynamic networking environments. Some experiments also introduce additional functionality, such as enhanced security or ability to effectively route through several IP addressing domains.
典型覆盖路由方法的最终结果是一种通信服务，其基本功能与经典IP提供的功能相当，但在动态网络环境中提供了比普通IP更好的恢复能力。一些实验还引入了额外的功能，如增强的安全性或有效路由几个IP寻址域的能力。
The authors expect ORCHIDs to become fully routable, via one or more overlay systems, before the end of the experiment.
作者期望兰花在实验结束前通过一个或多个覆盖系统完全可路由。
As noted above, the aim is that ORCHIDs are globally unique in a statistical sense. That is, given the ORCHID referring to a given entity, the probability of the same ORCHID being used to refer to another entity elsewhere in the Internet must be sufficiently low so that it can be ignored for most practical purposes. We believe that the presented design meets this goal; see Section 5.
如上所述，目的是兰花在统计意义上是全球独一无二的。也就是说，鉴于兰花指的是一个给定的实体，同一兰花在互联网其他地方被用于指代另一个实体的概率必须足够低，以便在大多数实际情况下可以忽略它。我们相信所提出的设计符合这一目标；见第5节。
Consider next the very rare case that some ORCHID happens to refer to two different entities at the same time, at two different locations in the Internet. Even in this case, the probability of this fact becoming visible (and therefore a matter of consideration) at any
下一个非常罕见的情况是，一些兰花同时出现在两个不同的实体，在互联网的两个不同的位置。即使在这种情况下，这一事实在任何时候都是可见的（因此是一个值得考虑的问题）
single location in the Internet is negligible. For the vast majority of cases, the two simultaneous uses of the ORCHID will never cross each other. However, while rare, such collisions are still possible. This section gives reasonable guidelines on how to mitigate the consequences in the case that such a collision happens.
互联网上的单一位置可以忽略不计。在绝大多数情况下，兰花的两种同时使用永远不会相互交叉。然而，尽管这种碰撞很少见，但仍然有可能发生。本节给出了在发生此类碰撞时如何减轻后果的合理指南。
As mentioned above, ORCHIDs are expected to be used at the legacy IPv6 APIs between consenting hosts. The context ID is intended to differentiate between the various experiments, or contexts, sharing the ORCHID namespace. However, the context ID is not present in the ORCHID itself, but only in front of the input bitstring as an input to the hash function. While this may lead to certain implementation-related complications, we believe that the trade-off of allowing the hash result part of an ORCHID being longer more than pays off the cost.
如上所述，兰花预计将在同意的主机之间的传统IPv6 API中使用。上下文ID用于区分共享兰花名称空间的各种实验或上下文。但是，上下文ID不存在于兰花本身中，而仅存在于作为哈希函数输入的输入位字符串前面。虽然这可能会导致某些与实现相关的复杂情况，但我们认为，允许兰花的哈希结果部分的长度超过成本的代价。
Because ORCHIDs are not routable at the IP layer, in order to send packets using ORCHIDs at the API level, the sending host must have additional overlay state within the stack to determine which parameters (e.g., what locators) to use in the outgoing packet. An underlying assumption here, and a matter of fact in the proposals that the authors are aware of, is that there is an overlay protocol for setting up and maintaining this additional state. It is assumed that the state-set-up protocol carries the input bitstring, and that the resulting ORCHID-related state in the stack can be associated back with the appropriate context and state-set-up protocol.
由于兰花在IP层不可路由，为了在API级别使用兰花发送数据包，发送主机必须在堆栈中具有额外的覆盖状态，以确定在传出数据包中使用哪些参数（例如，什么定位器）。这里的一个基本假设，以及作者所知道的提案中的一个事实，是有一个覆盖协议用于建立和维护这个附加状态。假设状态设置协议携带输入位字符串，并且堆栈中产生的与兰花相关的状态可以与适当的上下文和状态设置协议相关联。
Even though ORCHID collisions are expected to be extremely rare, two kinds of collisions may still happen. First, it is possible that two different input bitstrings within the same context may map to the same ORCHID. In this case, the state-set-up mechanism is expected to resolve the conflict, for example, by indicating to the peer that the ORCHID in question is already in use.
尽管兰花碰撞预计极为罕见，但仍可能发生两种碰撞。首先，同一上下文中的两个不同输入位字符串可能映射到同一个兰花。在这种情况下，状态设置机制有望解决冲突，例如，通过向对等方指示相关兰花已经在使用中。
A second type of collision may happen if two input bitstrings, used in different usage contexts, map to the same ORCHID. In this case, the main confusion is about which context to use. In order to prevent these types of collisions, it is RECOMMENDED that implementations that simultaneously support multiple different contexts maintain a node-wide unified database of known ORCHIDs, and indicate a conflict if any of the mechanisms attempt to register an ORCHID that is already in use. For example, if a given ORCHID is already being used as a HIT in HIP, it cannot simultaneously be used as a TMI in Mobile IP. Instead, if Mobile IP attempts to use the ORCHID, it will be notified (by the kernel) that the ORCHID in question is already in use.
如果在不同使用上下文中使用的两个输入位字符串映射到同一个兰花，则可能发生第二种类型的冲突。在这种情况下，主要的困惑在于使用哪种上下文。为了防止这些类型的冲突，建议同时支持多个不同上下文的实现维护一个节点范围的已知兰花统一数据库，并在任何机制试图注册已在使用的兰花时指示冲突。例如，如果一个给定的兰花已经被用作HIP中的HIT，那么它不能同时被用作移动IP中的TMI。相反，如果移动IP试图使用兰花，它将（通过内核）收到有关兰花已经在使用的通知。
The design of this namespace faces two competing forces:
此名称空间的设计面临两种相互竞争的力量：
o As many bits as possible should be preserved for the hash result.
o 应为哈希结果保留尽可能多的位。
o It should be possible to share the namespace between multiple mechanisms.
o 应该可以在多个机制之间共享名称空间。
The desire to have a long hash result requires that the prefix be as short as possible, and use few (if any) bits for additional encoding. The present design takes this desire to the maxim: all the bits beyond the prefix are used as hash output. This leaves no bits in the ORCHID itself available for identifying the context. Additionally, due to security considerations, the present design REQUIRES that the hash function used in constructing ORCHIDs be constant; see Section 6.
想要得到一个长的散列结果，需要前缀尽可能短，并使用少量（如果有的话）位进行额外编码。目前的设计最大限度地满足了这一需求：前缀之外的所有位都用作哈希输出。这使得兰花本身中没有任何比特可用于识别上下文。此外，出于安全考虑，本设计要求用于构造兰花的散列函数为常量；见第6节。
The authors explicitly considered including a hash-extension mechanism, similar to the one in CGA [RFC3972], but decided to leave it out. There were two reasons: desire for simplicity, and the somewhat unclear IPR situation around the hash-extension mechanism. If there is a future revision of this document, we strongly advise the future authors to reconsider the decision.
作者明确考虑包括一个散列扩展机制，类似于CGA[RFC3972]中的散列扩展机制，但决定省略它。有两个原因：对简单性的渴望，以及围绕哈希扩展机制的知识产权情况有些不清楚。如果本文件将来有修订，我们强烈建议未来的作者重新考虑该决定。
The desire to allow multiple mechanisms to share the namespace has been resolved by including the context identifier in the hash-function input. While this does not allow the mechanism to be directly inferred from a ORCHID, it allows one to verify that a given input bitstring and ORCHID belong to a given context, with high-probability; but also see Section 6.
通过在哈希函数输入中包含上下文标识符，可以解决允许多个机制共享名称空间的问题。虽然这不允许直接从兰花推断出机制，但它允许以高概率验证给定的输入位字符串和兰花是否属于给定的上下文；但也见第6节。
ORCHIDs are designed to be securely bound to the Context ID and the bitstring used as the input parameters during their generation. To provide this property, the ORCHID generation algorithm relies on the second-preimage resistance (a.k.a. one-way) property of the hash function used in the generation [RFC4270]. To have this property and to avoid collisions, it is important that the allocated prefix is as short as possible, leaving as many bits as possible for the hash output.
兰花被设计为在生成过程中安全地绑定到上下文ID和用作输入参数的位字符串。为了提供此属性，兰花生成算法依赖于生成中使用的哈希函数的第二个前图像阻力（也称为单向）属性[RFC4270]。要拥有此属性并避免冲突，分配的前缀必须尽可能短，为哈希输出保留尽可能多的位。
For a given Context ID, all mechanisms using ORCHIDs MUST use exactly the same mechanism for generating an ORCHID from the input bitstring. Allowing different mechanisms, without explicitly encoding the mechanism in the Context ID or the ORCHID itself, would allow so-called bidding-down attacks. That is, if multiple different hash
对于给定的上下文ID，所有使用兰花的机制必须使用与从输入位字符串生成兰花完全相同的机制。允许不同的机制，而不在上下文ID或兰花本身中显式地编码该机制，将允许所谓的向下竞价攻击。也就是说，如果有多个不同的散列
functions were allowed to construct ORCHIDs valid for the same Context ID, and if one of the hash functions became insecure, that would allow attacks against even those ORCHIDs valid for the same Context ID that had been constructed using the other, still secure hash functions.
函数被允许构造对同一上下文ID有效的兰花，如果其中一个哈希函数变得不安全，那么即使那些对使用另一个仍然安全的哈希函数构造的相同上下文ID有效的兰花也会受到攻击。
Due to the desire to keep the hash output value as long as possible, the hash function is not encoded in the ORCHID itself, but rather in the Context ID. Therefore, the present design allows only one method per given Context ID for constructing ORCHIDs from input bitstrings. If other methods (perhaps using more secure hash functions) are later needed, they MUST use a different Context ID. Consequently, the suggested method to react to the hash result becoming too short, due to increased computational power, or to the used hash function becoming insecure due to advances in cryptology, is to allocate a new Context ID and cease to use the present one.
由于希望尽可能长地保持散列输出值，散列函数不在兰花本身中编码，而是在上下文ID中编码。因此，目前的设计仅允许每个给定上下文ID使用一种方法从输入位字符串构造兰花。如果以后需要其他方法（可能使用更安全的散列函数），则它们必须使用不同的上下文ID。因此，建议的方法对散列结果变得太短作出反应，这是由于计算能力的提高，或者由于密码学的进展，所使用的散列函数变得不安全，是分配一个新的上下文ID并停止使用当前的上下文ID。
As of today, SHA1 [RFC3174] is considered as satisfying the second-preimage resistance requirement. The current version of the HIP specification defines SHA1 [RFC3174] as the hash function to be used to generate ORCHIDs for the Context ID used by the HIP protocol [HIP-BASE].
截至今天，SHA1[RFC3174]被认为满足第二个前像电阻要求。HIP规范的当前版本将SHA1[RFC3174]定义为哈希函数，用于为HIP协议[HIP-BASE]使用的上下文ID生成兰花。
In order to preserve a low enough probability of collisions (see Section 4), each method MUST utilize a mechanism that makes sure that the distinct input bitstrings are either unique or statistically unique within that context. There are several possible methods to ensure this; for example, one can include into the input bitstring a globally maintained counter value, a pseudo-random number of sufficient entropy (minimum 100 bits), or a randomly generated public cryptographic key. The Context ID makes sure that input bitstrings from different contexts never overlap. These together make sure that the probability of collisions is determined only by the probability of natural collisions in the hash space and is not increased by a possibility of colliding input bitstrings.
为了保持足够低的冲突概率（见第4节），每种方法必须利用一种机制，确保不同的输入位字符串在该上下文中是唯一的或统计上唯一的。有几种可能的方法来确保这一点；例如，可以在输入比特串中包括全局维护的计数器值、足够熵的伪随机数（最小100位）或随机生成的公钥。上下文ID确保来自不同上下文的输入位字符串不会重叠。这些共同确保冲突的概率仅由哈希空间中自然冲突的概率决定，而不因输入位字符串冲突的可能性而增加。
IANA allocated a temporary non-routable 28-bit prefix from the IPv6 address space. By default, the prefix will be returned to IANA in 2014, continued use requiring IETF consensus. As per [RFC4773], the 28-bit prefix was drawn out of the IANA Special Purpose Address Block, namely 2001:0000::/23, in support of the experimental usage described in this document. IANA has updated the IPv6 Special Purpose Address Registry.
IANA从IPv6地址空间分配了一个临时的不可路由的28位前缀。默认情况下，前缀将在2014年返回IANA，继续使用需要IETF协商一致。根据[RFC4773]，从IANA专用地址块中提取28位前缀，即2001:0000:：/23，以支持本文档中描述的实验性用法。IANA已更新IPv6专用地址注册表。
During the discussions related to this document, it was suggested that other identifier spaces may be allocated from this block later. However, this document does not define such a policy or allocations.
在与本文件相关的讨论中，有人建议以后从该区块分配其他标识符空间。但是，本文件并未定义此类政策或分配。
The Context Identifier (or Context ID) is a randomly generated value defining the usage context of an ORCHID and the hash function to be used for generation of ORCHIDs in this context. This document defines no specific value.
上下文标识符（或上下文ID）是一个随机生成的值，用于定义兰花的使用上下文以及在此上下文中用于生成兰花的哈希函数。本文档未定义特定值。
We propose sharing the name space introduced for CGA Type Tags. Hence, defining new values would follow the rules of Section 8 of [RFC3972], i.e., on a First Come First Served basis.
我们建议共享为CGA类型标记引入的名称空间。因此，定义新值将遵循[RFC3972]第8节的规则，即先到先得。
Special thanks to Geoff Huston for his sharp but constructive critique during the development of this memo. Tom Henderson helped to clarify a number of issues. This document has also been improved by reviews, comments, and discussions originating from the IPv6, Internet Area, and IETF communities.
特别感谢Geoff Huston在编写本备忘录过程中提出的尖锐但建设性的批评。汤姆·亨德森帮助澄清了一些问题。本文档还通过来自IPv6、互联网领域和IETF社区的审查、评论和讨论得到了改进。
Julien Laganier is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission.
Julien Laganier的部分资金来自Ambient Networks，这是一个由欧盟委员会第六个框架计划支持的研究项目。本文中包含的观点和结论是作者的观点和结论，不应被解释为必然代表Ambient Networks项目或欧盟委员会的官方政策或认可（无论明示或暗示）。
[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月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[HIP-BASE] Moskowitz, R., "Host Identity Protocol", Work in Progress, February 2007.
[HIP-BASE]Moskowitz，R.，“主机身份协议”，正在进行的工作，2007年2月。
[Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity Indirection Infrastructure (Hi3)", November 2004.
[Hi3]Nikander，P.，Arkko，J.和B.Ohlman，“主机身份间接寻址基础设施（Hi3）”，2004年11月。
[NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A Node Identity Internetworking Architecture (NodeID)", April 2006.
[NodeID]Ahlgren，B.，Arkko，J.，Eggert，L.，和J.Rajahalme，“节点身份互联架构（NodeID）”，2006年4月。
[PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension for Mobile IPv6", Work in Progress, July 2006.
杜邦，F.，“移动IPv6的简单隐私扩展”，正在进行的工作，2006年7月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4773] Huston, G., "Administration of the IANA Special Purpose IPv6 Address Block", RFC 4773, December 2006.
[RFC4773]Huston，G.“IANA专用IPv6地址块的管理”，RFC 4773，2006年12月。
Authors' Addresses
作者地址
Pekka Nikander Ericsson Research Nomadic Lab JORVAS FI-02420 Finland
佩卡·尼坎德·爱立信游牧研究实验室JORVAS FI-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
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
Francis Dupont CELAR
弗朗西斯·杜邦·塞拉
EMail: Francis.Dupont@fdupont.fr
EMail: Francis.Dupont@fdupont.fr
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编辑功能的资金目前由互联网协会提供。