Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 7343 Luminate Wireless, Inc.
Obsoletes: 4843 F. Dupont
Category: Standards Track Internet Systems Consortium
ISSN: 2070-1721 September 2014
Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 7343 Luminate Wireless, Inc.
Obsoletes: 4843 F. Dupont
Category: Standards Track Internet Systems Consortium
ISSN: 2070-1721 September 2014
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
覆盖可路由加密哈希标识符版本2（V2）的IPv6前缀
Abstract
摘要
This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) 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 regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.
本文档指定了一种更新的覆盖可路由加密哈希标识符（RAYD）格式，该格式淘汰了RFC 4843中的格式。这些标识符旨在用作应用程序和应用程序编程接口（API）的端点标识符，而不是用作IP层网络位置的标识符，即定位器。它们被设计为作为应用层实体出现在现有的IPv6 API中，但不应出现在实际的IPv6头中。为了使它们更像常规的IPv6地址，它们应该可以在覆盖层上路由。因此，虽然从IPv6层的角度来看，它们被视为不可路由地址，但所有现有IPv6应用程序都希望能够以与当前IPv6地址兼容的方式使用它们。
The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.
最初在RFC 4843中定义的覆盖可路由加密哈希标识符缺乏加密算法灵活性的机制。本文档中指定的更新兰花格式通过在标识符本身中编码所用加密算法套件的索引来消除此限制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7343.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7343.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected Use of ORCHIDs . . . . . . . . . . . . . . . . . 5
1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Hash Identifier Construction . . . . . . . . . 5
3. Routing and Forwarding Considerations . . . . . . . . . . . . 7
4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Collision Considerations . . . . . . . . . . . . . . 13
Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected Use of ORCHIDs . . . . . . . . . . . . . . . . . 5
1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Hash Identifier Construction . . . . . . . . . 5
3. Routing and Forwarding Considerations . . . . . . . . . . . . 7
4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Collision Considerations . . . . . . . . . . . . . . 13
Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 13
This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID), a new class of identifiers that are like IP addresses. These identifiers are intended to be globally unique in a statistical sense (see Appendix A), 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地址的新型标识符。这些标识符在统计意义上是全局唯一的（见附录a），在IP层不可路由，在某些覆盖层可路由。标识符通过安全哈希函数安全地绑定到输入位字符串和上下文标记的串联。通常，但不一定，输入比特串将包括适当编码的公钥。
These identifiers are expected to be used at the existing IPv6 Application Programming Interfaces (APIs) 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 (HITs) in the Host Identity Protocol (HIP) [HIPv2] and Temporary Mobile Identifiers (TMIs) for Mobile IPv6 Privacy Extension [PRIVACYTEXT].
这些标识符预计将用于同意主机之间的现有IPv6应用程序编程接口（API）和应用程序协议。它们可以在不同的上下文中定义和使用，适用于不同的覆盖协议。这些示例包括主机标识协议（HIP）[HIPv2]中的主机标识标签（HITs）和用于移动IPv6隐私扩展[PRIVACYTEXT]的临时移动标识符（TMI）。
As these identifiers are expected to be used along with IPv6 addresses at both applications and APIs, coordination is desired to make sure that an ORCHID is not inappropriately taken for a regular 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 use at the IP layer.
由于这些标识符预计将在应用程序和API中与IPv6地址一起使用，因此需要进行协调，以确保不会不适当地将兰花用作常规IPv6地址，反之亦然。在实践中，为兰花分配一个单独的前缀似乎就足够了，这样可以使它们与上层的IPv6地址兼容，同时也可以避免在IP层使用它们。
While being technically possible to use ORCHIDs between consenting hosts without any coordination with the IETF and the IANA, the IETF would consider such practice potentially dangerous. A specific danger would be realized 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 balkanization of the Internet, similar to what has happened as a result of historical hijackings of IPv4 addresses that are not RFC 1918 [RFC1918] for private use.
IETF在技术上可能在同意主机之间使用兰花而不与IETF和IANA进行协调，IETF会认为这种做法具有潜在的危险性。如果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 implement with protocol stack extensions, such as secure overlay routing, HIP, or
然而，考虑到因特网的当前状态，我们不认为引入任何修改，即需要修改应用程序和更新主机堆栈是可行的。与此相反，我们相信逐段的体系结构更改，只需要触及现有资产中的一项。兰花旨在解决这种情况：允许人们使用协议栈扩展来实现，例如安全覆盖路由、HIP或
Mobile IP privacy extensions, without requiring them to update their applications. The goal is to facilitate large-scale deployments with minimum user effort.
移动IP隐私扩展，无需更新应用程序。目标是以最少的用户努力促进大规模部署。
For example, at the time of this writing, there already exist 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使用它们。
The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.
最初在[RFC4843]中定义的覆盖可路由加密哈希标识符缺乏加密算法灵活性的机制。本文档中指定的更新兰花格式通过在标识符本身中编码所用加密算法套件的索引来消除此限制。
Because the updated ORCHIDv2 format is not backward compatible, IANA has allocated a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily allocated for the experimental ORCHID was returned to IANA in March 2014 [RFC4843].
由于更新后的Vv2格式不向后兼容，IANA已根据[RFC6890]从IANA IPv6专用地址块中分配了一个新的28位前缀，即2001:0000:：/23。2014年3月，临时分配给实验兰花的前缀返回给IANA[RFC4843]。
ORCHIDs are designed to have the following properties:
兰花具有以下特性：
o Statistical uniqueness (see also Appendix A).
o 统计唯一性（另见附录A）。
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 coordination need as indicated above. Without such coordination 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 Appendix A for a
如上所述，兰花旨在在不同的环境中生成和使用，以适合不同的机制和协议。上下文标识符用于区分不同的上下文；有关详细信息，请参见附录A
discussion of the related API issues implementation issues and Section 4 for the design choices explaining why the Context Identifiers are used.
讨论相关的API问题、实现问题和第4节的设计选择，解释为什么使用上下文标识符。
Examples of identifiers and protocols that are expected to adopt the ORCHID format include Host Identity Tags (HITs) in the Host Identity Protocol [HIPv2] and the Temporary Mobile Identifiers (TMIs) 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.
预期采用兰花格式的标识符和协议的示例包括主机标识协议[HIPv2]中的主机标识标签（HITs）和移动IPv6的简单隐私扩展[PRIVACYTEXT]中的临时移动标识符（TMI）。该格式设计为可扩展的，以允许其他实验方案共享同一名称空间。
This document requests IANA to allocate a 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 ORCHID Generation Algorithm (OGA). The algorithm takes a bitstring and a Context Identifier as input and produces an ORCHID as output. The hash function used in the ORCHID Generation Algorithm is defined for each OGA identifier by the specification for the respective usage context (e.g., HIPv2).
兰花是使用兰花生成算法（OGA）生成的。该算法将一个位字符串和一个上下文标识符作为输入，并生成一个兰花作为输出。兰花生成算法中使用的哈希函数由各自使用上下文（例如HIPv2）的规范为每个OGA标识符定义。
Input := any bitstring
OGA ID := 4-bit Orchid Generation Algorithm identifier
Hash Input := Context ID | Input
Hash := Hash_function( Hash Input )
ORCHID := Prefix | OGA ID | Encode_96( Hash )
Input := any bitstring
OGA ID := 4-bit Orchid Generation Algorithm identifier
Hash Input := Context ID | Input
Hash := Hash_function( Hash Input )
ORCHID := Prefix | OGA ID | Encode_96( 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 Cryptographically Generated Addresses (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).
OGA ID : A 4-bit-long identifier for the Hash_function in use within the specific usage context.
OGA ID：在特定使用上下文中使用的哈希函数的4位长标识符。
Hash_function : The one-way hash function (i.e., hash function with preimage resistance and second-preimage resistance) to be used as identified by the value for the OGA ID according document defining the context usage identified by the Context ID. For example, version 2 of the HIP specification defines truncated SHA1 [RFC3174] as the hash function to be used to generate ORCHIDv2 in the HIPv2 protocol when the OGA ID is 3 [HIPv2].
Hash_函数：根据定义上下文ID标识的上下文使用的文档，由OGA ID值标识的单向哈希函数（即，具有前映像阻力和第二前映像阻力的哈希函数）。例如，HIP规范的版本2定义了截断的SHA1[RFC3174]当OGA ID为3[HIPv2]时，作为用于在HIPv2协议中生成HIPv2的哈希函数。
Encode_96( ) : An extraction function in which output is obtained by extracting the middle 96-bit-long bitstring from the argument bitstring.
Encode_96（）：一种提取函数，通过从参数位字符串中提取中间96位长的位字符串来获得输出。
Prefix : A constant 28-bit-long bitstring value (2001:20::/28).
前缀：恒定的28位长的位字符串值（2001:20:：/28）。
To form an ORCHID, two pieces of input data are needed. The first piece can be any bitstring, but it 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 6. Each specific ORCHIDv2 application (such as HIP HITs or MIP6 TMIs) is expected to allocate their own, specific Context Identifier.
上下文标识符，是一个128位长的数据，按照第6节的规定分配。每个特定的应用程序（如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 for the value of the OGA identifier 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 96-bit-long value. This value is prepended with the concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. 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标识的上下文用法的文档，将输入数据馈送至加密哈希函数以用于OGA标识符的值。哈希函数的结果由编码函数处理，产生一个96位长的值。此值以28位兰花前缀和4位OGA ID的串联作为前缀。结果是兰花，一个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目标不可到达、管理禁止的消息。
ORCHIDs are not designed for use in IPv6 routing protocols, since such routing protocols are based on the architectural definition of IPv6 addresses. Future non-IPv6 routing systems, such as overlay routing systems, may be designed based on ORCHIDs. Any such ORCHID-based routing system is out of scope of this document.
兰花不是为在IPv6路由协议中使用而设计的，因为此类路由协议基于IPv6地址的体系结构定义。未来的非IPv6路由系统，例如覆盖路由系统，可能会基于兰花设计。任何此类基于兰花的路由系统都不在本文档的范围内。
Router software MUST NOT include any special handling code for ORCHIDs. In other words, the non-routability property of ORCHIDs, if implemented, is to be implemented via configuration rather than by hardwired software code, e.g., the ORCHID prefix can be blocked by a simple configuration rule such as an Access Control List entry.
路由器软件不得包含任何兰花专用处理代码。换句话说，如果实现了兰花的非路由性属性，则将通过配置而不是通过硬连线软件代码来实现，例如，兰花前缀可以通过简单的配置规则（例如访问控制列表条目）来阻止。
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 maximum: all the bits beyond the prefix and the ORCHID Generation Algorithm Identifier are used as hash output. This leaves no bits in the ORCHID itself available for identifying the context; however, the 4 bits used to encode the ORCHID Generation Algorithm Identifier provides cryptographic agility with respect to the hash function in use for a given context (see Section 5).
想要得到一个长的散列结果，需要前缀尽可能短，并使用少量（如果有的话）位进行额外编码。目前的设计最大限度地满足了这一需求：前缀和兰花生成算法标识符之外的所有位都用作哈希输出。这使得兰花本身没有任何部分可用于识别上下文；然而，用于编码兰花生成算法标识符的4位提供了针对给定上下文使用的哈希函数的加密灵活性（参见第5节）。
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 an 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 5).
通过在哈希函数输入中包含上下文标识符，可以解决允许多个机制共享名称空间的问题。虽然这不允许直接从一个兰花推断出该机制，但它允许以高概率验证给定的输入位字符串和兰花是否属于给定的上下文（但也请参见第5节）。
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 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或兰花本身中显式地编码该机制，将允许所谓的向下竞价攻击。也就是说，如果允许多个不同的散列函数构造对同一上下文ID有效的兰花，并且如果其中一个散列函数变得不安全，那么即使是那些对使用另一个仍然安全的散列函数构造的相同上下文ID有效的兰花，也会允许攻击。
An identifier for the hash function to be used for the ORCHID generation is encoded in the ORCHID itself, while the semantic for the values taken by this identifier are defined separately for each Context ID. Therefore, the present design allows the use of different hash functions per given Context ID for constructing ORCHIDs from input bitstrings. The intent is that the protocol or application using an ORCHIDv2 allocates a Context ID for that use and defines, within the scope of that Context ID, the registry for the ORCHID Generation Algorithm (OGA) ID. The rationale for this is to allow different applications to use different hash functions that best satisfy their specific requirements, such that the relatively small OGA ID namespace (4 bits wide, i.e., 16 different values) does not get exhausted too quickly. If more secure hash functions are later needed, newer values for the ORCHID Generation Algorithm can be defined for the given Context ID.
将用于生成兰花的哈希函数的标识符编码在兰花本身中，而该标识符获取的值的语义分别为每个上下文ID定义。因此，目前的设计允许根据给定的上下文ID使用不同的哈希函数，以便从输入位字符串构造兰花。其目的是，使用兰花V2的协议或应用程序为该用途分配一个上下文ID，并在该上下文ID的范围内定义兰花生成算法（OGA）ID的注册表。其基本原理是允许不同的应用程序使用最能满足其特定要求的不同哈希函数，这样相对较小的OGA ID名称空间（4位宽，即16个不同的值）不会太快耗尽。如果以后需要更安全的散列函数，可以为给定的上下文ID定义兰花生成算法的新值。
In order to preserve a low enough probability of collisions (see Appendix A), 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 pseudorandom number of sufficient entropy (minimum 96 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.
为了保持足够低的冲突概率（见附录a），每种方法必须利用一种机制，确保不同的输入位串在该上下文中是唯一的或统计上唯一的。有几种可能的方法来确保这一点；例如，可以将全局维护的计数器值、足够熵的伪随机数（最小96位）或随机生成的公钥包括到输入比特串中。上下文ID确保来自不同上下文的输入位字符串不会重叠。这些共同确保冲突的概率仅由哈希空间中自然冲突的概率决定，而不因输入位字符串冲突的可能性而增加。
The generation of an ORCHIDv2 identifier from an input bitstring involves truncation of a hash output to construct a fixed-size identifier in a fashion similar to the scheme specified in "Naming Things with Hashes" [RFC6920]. Accordingly, the Security Considerations of [RFC6920] pertaining to truncation of the hash output during identifier generation are also applicable to ORCHIDv2 generation.
从输入位字符串生成标识符涉及截断散列输出，以类似于“用散列命名事物”[RFC6920]中指定的方案的方式构造固定大小的标识符。因此，[RFC6920]关于标识符生成期间哈希输出的截断的安全考虑也适用于标识符生成。
Because the updated ORCHIDv2 format is not backward compatible with the earlier one, IANA has allocated a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily allocated for the experimental ORCHID was returned to IANA in March 2014 [RFC4843]. The registry information for the allocation is as follows:
由于更新后的Vv2格式与以前的格式不向后兼容，IANA已根据[RFC6890]从IANA IPv6专用地址块中分配了一个新的28位前缀，即2001:0000:：/23。2014年3月，临时分配给实验兰花的前缀返回给IANA[RFC4843]。分配的注册表信息如下：
o Address Block: 2001:20::/28
o 地址栏：2001:20:：/28
o Name: ORCHIDv2
o 名称：兰花
o RFC: RFC 7343
o RFC:RFC 7343
o Allocation Date: 2014-07
o 分配日期：2014-07
o Termination Date: N/A
o 终止日期：不适用
o Source: True
o 资料来源：真实
o Destination: True
o 目的地：正确
o Forwardable: True
o 可转发：正确
o Global: True
o 全球：真的
o Reserved-by-Protocol: False
o 协议保留：False
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. The Context ID shares the namespace introduced for CGA Type Tags. Hence, defining new values follows the rules of Section 8 of [RFC3972], i.e., First Come, First Served. However, no IANA actions are required.
上下文标识符（或上下文ID）是一个随机生成的值，用于定义兰花的使用上下文以及在此上下文中用于生成兰花的哈希函数。本文档未定义特定值。上下文ID共享为CGA类型标记引入的命名空间。因此，定义新值遵循[RFC3972]第8节的规则，即先到先得。但是，不需要IANA行动。
Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an earlier, experimental version of this specification [RFC4843].
佩卡·尼坎德（佩卡。nikander@nomadiclab.com)共同编写了本规范的早期实验版本[RFC4843]。
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社区的审查、评论和讨论得到了改进。
[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月。
[HIPv2] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", Work in Progress, July 2014.
[HIPv2]Moskowitz，R.，Heer，T.，Jokela，P.，和T.Henderson，“主机身份协议版本2（HIPv2）”，正在进行的工作，2014年7月。
[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月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843]Nikander，P.，Laganier，J.，和F.Dupont，“覆盖可路由加密哈希标识符（RAYD）的IPv6前缀”，RFC 4843，2007年4月。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April 2013.
[RFC6890]Cotton，M.，Vegoda，L.，Bonica，R.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 68902013年4月。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
[RFC6920]Farrell，S.，Kutscher，D.，Dannewitz，C.，Ohlman，B.，Keranen，A.，和P.Hallam Baker，“用哈希命名事物”，RFC 6920，2013年4月。
As noted earlier, the aim is that so long as keys are not reused, ORCHIDs be 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 4).
如前所述，其目的是，只要不重复使用密钥，兰花在统计意义上就具有全球唯一性。也就是说，鉴于兰花指的是一个给定的实体，同一兰花在互联网其他地方被用于指代另一个实体的概率必须足够低，以便在大多数实际情况下可以忽略它。我们相信所提出的设计符合这一目标（见第4节）。
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 is 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-setup 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-setup protocol.
由于兰花在IP层不可路由，为了在API级别使用兰花发送数据包，发送主机必须在堆栈中具有额外的覆盖状态，以确定在传出数据包中使用哪些参数（例如，什么定位器）。这里的一个基本假设，以及作者所知道的提案中的一个事实，是有一个覆盖协议用于建立和维护这个附加状态。假设状态设置协议携带输入位字符串，并且堆栈中产生的与兰花相关的状态可以与适当的上下文和状态设置协议相关联。
o Updated HIP references to revised HIP specifications.
o 更新髋关节参考，以修订髋关节规范。
o The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.
o 最初在[RFC4843]中定义的覆盖可路由加密哈希标识符缺乏加密算法灵活性的机制。本文档中指定的更新兰花格式通过在标识符本身中编码所用加密算法套件的索引来消除此限制。
o Moved the "Collision Considerations" section into an appendix and removed unnecessary discussions.
o 将“碰撞注意事项”部分移至附录中，并删除了不必要的讨论。
o Removed the discussion on overlay routing.
o 删除了关于覆盖路由的讨论。
Authors' Addresses
作者地址
Julien Laganier Luminate Wireless, Inc. Cupertino, CA USA
Julien Laganier Luminate Wireless，Inc.美国加利福尼亚州库珀蒂诺市
EMail: julien.ietf@gmail.com
EMail: julien.ietf@gmail.com
Francis Dupont Internet Systems Consortium
弗朗西斯·杜邦互联网系统联盟
EMail: fdupont@isc.org
EMail: fdupont@isc.org