Independent Submission E. Lear
Request for Comments: 6837 Cisco Systems GmbH
Category: Experimental January 2013
ISSN: 2070-1721
Independent Submission E. Lear
Request for Comments: 6837 Cisco Systems GmbH
Category: Experimental January 2013
ISSN: 2070-1721
NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database
NERD：路由定位器（RLOC）数据库的一个不太新颖的端点ID（EID）
Abstract
摘要
The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to-RLOC mappings scales well to at least 10^8 entries.
定位器/ID分离协议（LISP）是一种封装IP数据包的协议，以便允许终端站点彼此路由，而无需将路由从互联网的一端注入到另一端。本备忘录提供了一个实验数据库，并讨论了以可靠、可扩展和安全的方式将端点ID（EID）到路由定位器（RLOC）的映射传输到路由器的方法。我们的分析得出结论，所有EID到RLOC映射的传输可以很好地扩展到至少10^8个条目。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6837.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6837.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Base Assumptions . . . . . . . . . . . . . . . . . . . . . 4
1.3. What is NERD? . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
2.1. Database Updates . . . . . . . . . . . . . . . . . . . . . 7
2.2. Communications between ITR and ETR . . . . . . . . . . . . 8
2.3. Who are database authorities? . . . . . . . . . . . . . . 8
3. NERD Format . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. NERD Record Format . . . . . . . . . . . . . . . . . . . . 11
3.2. Database Update Format . . . . . . . . . . . . . . . . . . 12
4. NERD Distribution Mechanism . . . . . . . . . . . . . . . . . 12
4.1. Initial Bootstrap . . . . . . . . . . . . . . . . . . . . 12
4.2. Retrieving Changes . . . . . . . . . . . . . . . . . . . . 12
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Database Size . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Router Throughput versus Time . . . . . . . . . . . . . . 16
5.3. Number of Servers Required . . . . . . . . . . . . . . . . 16
5.4. Security Considerations . . . . . . . . . . . . . . . . . 18
5.4.1. Use of Public Key Infrastructures (PKIs) . . . . . . . 19
5.4.2. Other Risks . . . . . . . . . . . . . . . . . . . . . 21
6. Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 21
7. Other Distribution Mechanisms . . . . . . . . . . . . . . . . 22
7.1. What about DNS as a mapping retrieval model? . . . . . . . 22
7.2. Use of BGP and LISP+ALT . . . . . . . . . . . . . . . . . 24
7.3. Perhaps use a hybrid model? . . . . . . . . . . . . . . . 24
8. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . 24
8.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Generating and Verifying the Database Signature
with OpenSSL . . . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Base Assumptions . . . . . . . . . . . . . . . . . . . . . 4
1.3. What is NERD? . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
2.1. Database Updates . . . . . . . . . . . . . . . . . . . . . 7
2.2. Communications between ITR and ETR . . . . . . . . . . . . 8
2.3. Who are database authorities? . . . . . . . . . . . . . . 8
3. NERD Format . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. NERD Record Format . . . . . . . . . . . . . . . . . . . . 11
3.2. Database Update Format . . . . . . . . . . . . . . . . . . 12
4. NERD Distribution Mechanism . . . . . . . . . . . . . . . . . 12
4.1. Initial Bootstrap . . . . . . . . . . . . . . . . . . . . 12
4.2. Retrieving Changes . . . . . . . . . . . . . . . . . . . . 12
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Database Size . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Router Throughput versus Time . . . . . . . . . . . . . . 16
5.3. Number of Servers Required . . . . . . . . . . . . . . . . 16
5.4. Security Considerations . . . . . . . . . . . . . . . . . 18
5.4.1. Use of Public Key Infrastructures (PKIs) . . . . . . . 19
5.4.2. Other Risks . . . . . . . . . . . . . . . . . . . . . 21
6. Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 21
7. Other Distribution Mechanisms . . . . . . . . . . . . . . . . 22
7.1. What about DNS as a mapping retrieval model? . . . . . . . 22
7.2. Use of BGP and LISP+ALT . . . . . . . . . . . . . . . . . 24
7.3. Perhaps use a hybrid model? . . . . . . . . . . . . . . . 24
8. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . 24
8.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Generating and Verifying the Database Signature
with OpenSSL . . . . . . . . . . . . . . . . . . . . 30
The Locator/ID Separation Protocol (LISP) [RFC6830] separates an IP address used by a host and local routing system from the Locators advertised by BGP participants on the Internet in general, and in the Default-Free Zone (DFZ) in particular. It accomplishes this by establishing a mapping between globally unique Endpoint IDs (EIDs) and Routing Locators (RLOCs). This reduces the amount of state change that occurs on routers within the DFZ on the Internet, while enabling end sites to be multihomed.
定位器/ID分离协议（LISP）[RFC6830]通常将主机和本地路由系统使用的IP地址与BGP参与者在互联网上，特别是在默认自由区（DFZ）中公布的定位器分离。它通过在全局唯一端点ID（EID）和路由定位器（RLOC）之间建立映射来实现这一点。这减少了在因特网上DFZ内的路由器上发生的状态变化量，同时使终端站点能够多址。
In some mapping distribution approaches to LISP, the mapping is learned via data-triggered control messages between Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) through an alternate routing topology [RFC6836]. In other approaches of LISP, the mapping from EIDs to RLOCs is instead learned through some other means. This memo addresses different approaches to the problem, and specifies a Not-so-novel EID-to-RLOC Database (NERD) and methods to both receive the database and to receive updates.
在LISP的一些映射分发方法中，映射是通过数据触发的控制消息在入口隧道路由器（ITR）和出口隧道路由器（ETR）之间通过备用路由拓扑进行学习的[RFC6836]。在LISP的其他方法中，从EID到RLOCs的映射是通过其他方法学习的。本备忘录阐述了解决问题的不同方法，并指定了一个不太新颖的EID到RLOC数据库（NERD）以及接收数据库和接收更新的方法。
NERD is offered primarily as a way to avoid dropping packets, the underlying assumption being that dropping packets is bad for applications and end users. Those who do not agree with this underlying assumption may find that other approaches make more sense.
NERD主要是作为一种避免丢弃数据包的方法提供的，其基本假设是丢弃数据包对应用程序和最终用户有害。那些不同意这一基本假设的人可能会发现其他方法更有意义。
NERD is specified in such a way that the methods used to distribute or retrieve it may vary over time. Multiple databases are supported in order to allow for multiple data sources. An effort has been made to divorce the database from access methods so that both can evolve independently through experimentation and operational validation.
指定NERD的方式是，用于分发或检索它的方法可能随时间而变化。支持多个数据库以允许多个数据源。已经做出努力，将数据库与访问方法分离，以便两者都可以通过实验和操作验证独立发展。
This memo is based on experiments performed in the 2007-2009 time frame. At the time of its publication, the author is unaware of operational use of NERD. Those wishing to pursue NERD should consider the substantial amount of work left for the future. See Section 10 for more details.
本备忘录基于2007-2009年期间进行的实验。在其出版时，作者并不知道NERD的实际用途。那些想追求书呆子的人应该考虑为未来留下大量的工作。详见第10节。
In order to specify a mapping, it is important to understand how it will be used, and the nature of the data being mapped. In the case of LISP, the following assumptions are pertinent:
为了指定映射，了解如何使用映射以及映射数据的性质非常重要。对于LISP，以下假设是相关的：
o The data contained within the mapping changes only on provisioning or configuration operations, and is not intended to change when a link either fails or is restored. Some other mechanism, such as
o 映射中包含的数据仅在设置或配置操作时更改，并且不打算在链接出现故障或恢复时更改。其他一些机制，例如
the use of LISP Reachability Bits with mapping replies, handles healing operations, particularly when a tail circuit within a service provider's aggregate goes down. NERD can be used as a verification method to ensure that whatever operational mapping changes an ITR receives are authorized.
将LISP可达性位与映射回复一起使用，可以处理修复操作，特别是当服务提供商的聚合中的尾部电路出现故障时。NERD可用作一种验证方法，以确保ITR收到的任何操作映射更改都得到授权。
o While weight and priority are defined, these are not hop-by-hop metrics. Hence, the information contained within the mapping does not change based on where one sits within the topology.
o 虽然定义了权重和优先级，但它们不是逐跳度量。因此，映射中包含的信息不会根据拓扑中的位置而改变。
o Because a purpose of LISP is to reduce control-plane overhead by reducing "rate X state" complexity, updates to the mapping will be relatively rare.
o 由于LISP的目的是通过降低“速率X状态”的复杂性来减少控制平面开销，因此对映射的更新相对较少。
o Because NERD is designed to ease interdomain routing, its use is intended within the inter-domain environment. That is, NERD is best implemented at either the customer edge or provider edge, and there will be on the order of as many ITRs and EID-Prefixes as there are connections to Internet service providers by end customers.
o 由于NERD旨在简化域间路由，因此其用途是在域间环境中使用。也就是说，NERD最好在客户边缘或提供商边缘实施，并且ITR和EID前缀的数量与最终客户与互联网服务提供商的连接数量相同。
o As such, NERD cannot be the sole means to implement host mobility, although NERD may be in used in conjunction with other mechanisms.
o 因此，NERD不能成为实现主机移动性的唯一手段，尽管NERD可以与其他机制结合使用。
NERD is a Not-so-novel EID-to-RLOC Database. It consists of the following components:
NERD对于RLOC数据库来说并不新奇。它由以下组件组成：
1. a network database format;
1. 网络数据库格式；
2. a change distribution format;
2. 改变分发格式；
3. a database retrieval/bootstrapping method; and
3. 数据库检索/引导方法；和
4. a change distribution method.
4. 一种变化分布方法。
The network database format is compressible. However, at this time, we specify no compression method. NERD will make use of potentially several transport methods, but most notably HTTP [RFC2616]. HTTP has restart and compression capabilities. It is also widely deployed.
网络数据库格式是可压缩的。但是，此时，我们没有指定压缩方法。NERD可能会使用几种传输方法，但最显著的是HTTP[RFC2616]。HTTP具有重启和压缩功能。它也被广泛部署。
There exist many methods to show differences between two versions of a database or a file, UNIX's "diff" being the classic example. In this case, because the data is well structured and easily keyed, we can make use of a very simple format for version differences that
有许多方法可以显示数据库或文件的两个版本之间的差异，UNIX的“diff”就是典型的例子。在这种情况下，由于数据结构良好且易于键入，因此我们可以使用非常简单的格式来处理版本差异
simply provides a list of EID-to-RLOC mappings that have changed using the same record format as the database, and a list of EIDs that are to be removed.
只提供使用与数据库相同的记录格式更改的EID到RLOC映射列表，以及要删除的EID列表。
The reader is once again referred to [RFC6830] for a general glossary of terms related to LISP. The following terms are specific to this memo.
读者再次参考[RFC6830]了解与LISP相关的通用术语表。以下术语仅适用于本备忘录。
Base Distribution URI: An Absolute-URI as defined in Section 4.3 of [RFC3986] from which other references are relative. The base distribution URI is used to construct a URI to an EID-to-RLOC mapping database. If more than one NERD is known, then there will be one or more base distribution URIs associated with each (although each such base distribution URI may have the same value).
基本分布URI:[RFC3986]第4.3节中定义的绝对URI，其他引用与之相对。基本分发URI用于构造EID到RLOC映射数据库的URI。如果已知多个NERD，则将有一个或多个基本分发URI与每个相关联（尽管每个这样的基本分发URI可能具有相同的值）。
EID Database Authority: The authority that will sign database files and updates. It is the source of both.
EID数据库权限：对数据库文件和更新进行签名的权限。这是两者的根源。
The Authority: Shorthand for the EID Database Authority.
权限：EID数据库权限的简写。
NERD: Not-so-novel EID-to-RLOC Database.
书呆子：对RLOC数据库来说，EID并不新奇。
AFI Address Family Identifier.
AFI地址族标识符。
Pull Model: An architecture where clients pull only the information they need at any given time, such as when a packet arrives for forwarding.
Pull模型：一种架构，其中客户机在任何给定时间（例如数据包到达转发时）仅提取所需的信息。
Push Model: An architecture in which clients receive an entire dataset, containing data they may or may not require, such as mappings for EIDs that no host served is attempting to send to.
推送模型：一种体系结构，在这种体系结构中，客户端接收一个完整的数据集，其中包含它们可能需要或不需要的数据，例如没有主机试图发送到的EID映射。
Hybrid Model: An architecture in which some information is pushed toward the receiver from a source and some information is pulled by the receiver.
混合模型：一种结构，其中一些信息从源推送到接收器，而一些信息由接收器拉入。
Operational functions are split into two components: database updates and state exchange between ITR and ETR during a communication.
操作功能分为两个部分：数据库更新和通信期间ITR和ETR之间的状态交换。
What follows is a summary of how NERDs are generated and updated. Specifics can be found in Section 3. The general way in which NERD works is as follows:
下面是书呆子是如何产生和更新的。具体内容见第3节。NERD工作的一般方式如下：
1. A NERD is generated by an authority that allocates Provider-Independent (PI) addresses (e.g., IANA or a Regional Internet Registry (RIR)) that are used by sites as EIDs. As part of this process, the authority generates a digest for the database and signs it with a private key whose public key is part of an X.509 certificate. [ITU.X509.2000] That signature along with a copy of the authority's public key is included in the NERD.
1. NERD由分配独立于提供商（PI）地址（如IANA或区域互联网注册中心（RIR））的机构生成，这些地址由站点用作EID。作为此过程的一部分，管理局为数据库生成摘要，并使用私钥对其进行签名，私钥的公钥是X.509证书的一部分。[ITU.X509.2000]该签名以及管理局公钥的副本包含在NERD中。
2. The NERD is distributed to a group of well-known servers.
2. NERD被分配到一组著名的服务器上。
3. ITRs retrieve an initial copy of the NERD via HTTP when they come into service.
3. ITRs在NERD投入使用时通过HTTP检索其初始副本。
4. ITRs are preconfigured with a group of certificates whose private keys are used by database authorities to sign the NERD. This list of certificates should be configurable by administrators.
4. ITR预先配置了一组证书，数据库管理机构使用这些证书的私钥对NERD进行签名。此证书列表应由管理员配置。
5. ITRs next verify both the validity of the public key and the signed digest. If either fail validation, the ITR attempts to retrieve the NERD from a different source. The process iterates until either a valid database is found or the list of sources is exhausted.
5. ITRs接下来验证公钥和签名摘要的有效性。如果验证失败，ITR将尝试从其他来源检索NERD。该过程将迭代，直到找到有效的数据库或用尽源列表。
6. Once a valid NERD is retrieved, the ITR installs it into both non-volatile and local memory.
6. 一旦检索到有效的NERD，ITR会将其安装到非易失性内存和本地内存中。
7. At some point, the authority updates the NERD and increments the database version counter. At the same time, it generates a list of changes, which it also signs, as it does with the original database.
7. 在某些时候，管理局会更新NERD并增加数据库版本计数器。同时，它生成一个更改列表，并对其进行签名，就像对原始数据库所做的一样。
8. Periodically, ITRs will poll from their list of servers to determine if a new version of the database exists. When a new version is found, an ITR will attempt to retrieve a change file, using its list of preconfigured servers.
8. ITR将定期从其服务器列表中轮询，以确定是否存在新版本的数据库。当发现新版本时，ITR将尝试使用其预配置的服务器列表检索更改文件。
9. The ITR validates a change file just as it does the original database. Assuming the change file passes validation, the ITR installs new entries, overwrites existing ones, and removes empty entries, based on the content of the change file.
9. ITR验证更改文件的方式与验证原始数据库的方式相同。假设更改文件通过验证，ITR将根据更改文件的内容安装新条目，覆盖现有条目，并删除空条目。
As time goes on, it is quite possible that an ITR may probe a list of configured peers for a database or change file copy. It is equally possible that peers might advertise to each other the version number of their database. Such methods are not explored in depth in this memo but are mentioned for future consideration.
随着时间的推移，ITR很可能会探测数据库的已配置对等点列表或更改文件副本。对等方也有可能相互公布其数据库的版本号。本备忘录未对此类方法进行深入探讨，但将提及这些方法以供将来考虑。
[RFC6830] describes the basic approach to what happens when a packet arrives at an ITR, and what communications between the ITR and ETR take place. NERD provides an optimistic approach to establishing communications with an ETR that is responsible for a given EID-Prefix. State must be kept, however, on an ITR to determine whether that ETR is in fact reachable. It is expected that this is a common requirement across LISP mapping systems, and will be handled in the core LISP architecture.
[RFC6830]描述了数据包到达ITR时发生的情况以及ITR和ETR之间发生的通信的基本方法。NERD为与负责给定EID前缀的ETR建立通信提供了一种乐观的方法。然而，必须在ITR上保持状态，以确定ETR是否实际上是可访问的。预计这是整个LISP映射系统的共同需求，将在核心LISP体系结构中处理。
This memo does not specify who the database authority is. That is because there are several possible operational models. In each case, the number of database authorities is meant to be small so that ITRs need only keep a small list of authorities, similar to the way a name server might cache a list of root servers.
此备忘录未指定数据库授权人。这是因为有几种可能的运作模式。在每种情况下，数据库权限的数量都很小，因此ITR只需要保留一个小的权限列表，类似于名称服务器缓存根服务器列表的方式。
o A single database authority exists. In this case, all entries in the database are registered to a single entity, and that entity distributes the database. Because the EID space is provider-independent address space, there is no architectural requirement that address space be hierarchically distributed to anyone, as there is with provider-assigned address space. Hence, there is a natural affinity between the IANA function and the database authority function.
o 存在一个数据库授权。在这种情况下，数据库中的所有条目都注册到一个实体，该实体分发数据库。由于EID空间是独立于提供程序的地址空间，因此没有体系结构要求将地址空间分层分配给任何人，就像提供程序分配的地址空间一样。因此，IANA函数和数据库权限函数之间有着天然的相似性。
o Each region runs a database authority. In this case, provider-independent address space is allocated to either RIRs or to affiliates of such organizations of network operations guilds (NOGs). The benefit of this approach is that there is no single organization that controls the database. It allows one database authority to back up another. One could envision as many as ten database authorities in this scenario. One drawback to this
o 每个地区都有一个数据库管理机构。在这种情况下，独立于提供商的地址空间分配给RIR或网络运营协会（NOG）的此类组织的附属机构。这种方法的好处是没有单一的组织控制数据库。它允许一个数据库机构备份另一个数据库机构。在这种情况下，可以设想多达十个数据库权限。这有一个缺点
approach, however, is that any reference to a region imposes a notion of locality, thus potentially diminishing the split between Locator and identifier.
然而，这种方法是，对一个区域的任何引用都会强加一个局部性的概念，从而潜在地减少定位器和标识符之间的分离。
o Each country runs a database authority. This could occur should countries decide to regulate this function. While limiting the scope of any single database authority as the previous scenario describes, this approach would introduce some overhead as the list of database authorities would grow to as many as 200, and possibly more if jurisdictions within countries attempted to regulate the function. There are two drawbacks to this approach. First, as distribution of EIDs is driven to more local jurisdictions, an EID-Prefix is tied even more tightly to a location. Second, a large number of database authorities will demand some sort of discovery mechanism.
o 每个国家都有一个数据库管理局。如果各国决定监管这一职能，就可能发生这种情况。尽管如前一种情况所述，该方法限制了任何单一数据库权限的范围，但由于数据库权限列表将增加到多达200个，如果国家内的司法管辖区试图监管该功能，可能会增加一些开销。这种方法有两个缺点。首先，随着EID分发到更多的地方司法管辖区，EID前缀与位置的联系更加紧密。其次，大量数据库管理机构将需要某种发现机制。
o Independent operators manage database authorities. This has the appeals of being location independent and enabling competition for good performance. This method has the drawback of potentially requiring a discovery mechanism.
o 独立的操作员管理数据库权限。这具有独立于位置的吸引力，并且能够实现良好性能的竞争。这种方法的缺点是可能需要一种发现机制。
The latter two approaches are not mutually exclusive. While this specification allows for multiple databases, discovery mechanisms are left as future work.
后两种方法并非相互排斥。虽然此规范允许多个数据库，但发现机制仍将作为未来的工作。
The NERD consists of a header that contains a database version and a signature that is generated by ignoring the signature field and setting the authentication block length to 0 (NULL). The authentication block itself consists of a signature and a certificate whose private-key counterpart was used to generate the signature.
NERD由一个包含数据库版本的头和一个签名组成，该签名是通过忽略签名字段并将身份验证块长度设置为0（NULL）生成的。身份验证块本身由一个签名和一个证书组成，该证书的私钥副本用于生成签名。
Records are kept sorted in numeric order with AFI plus EID as primary key and prefix length as secondary. This is so that after a database update it should be possible to reconstruct the database to verify the digest signature, which may be retrieved separately from the database for verification purposes.
记录按数字顺序进行排序，AFI加EID作为主键，前缀长度作为辅助键。这样，在数据库更新之后，应该可以重建数据库以验证摘要签名，可以从数据库中单独检索摘要签名以进行验证。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Schema Vers=1 | DB Code | Database Name Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Database Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Database Version or 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Database Name |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 Block Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PKCS#7 Block Containing Certificate and Signature |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Schema Vers=1 | DB Code | Database Name Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Database Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Database Version or 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Database Name |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 Block Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PKCS#7 Block Containing Certificate and Signature |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Database Header
数据库头
The 'DB Code' field indicates 0 if what follows is an entire database or 1 if what follows is an update. The 'Database Version' field holds the database file version, which is incremented each time the complete database is generated by the authority. In the case of an update, the field indicates the new database file version, and the old database file version is indicated in the 'Old Database Version' field. The database file version is used by routers to determine whether or not they have the most current database.
“DB Code”字段指示0（如果后面的是整个数据库）或1（如果后面的是更新）。“Database Version”（数据库版本）字段保存数据库文件版本，该版本在管理局每次生成完整数据库时递增。在更新的情况下，该字段指示新的数据库文件版本，而旧的数据库文件版本在“旧数据库版本”字段中指示。路由器使用数据库文件版本来确定它们是否拥有最新的数据库。
The 'Database Name' field holds a DNS-ID, as specified in [RFC6125]. This is the name that will appear in the Subject field of the certificate used to verify the database. The purpose of the database name is to allow for more than one database. Such databases would be merged by the router. It is important that an EID-to-RLOC mapping be listed in no more than one database, lest inconsistencies arise. However, it may be possible to transition a mapping from one database to another. During the transition period, the mappings would be identical. When they are not, the resultant behavior will be undefined. The database name is padded with NULLs to the nearest fourth byte.
“数据库名称”字段包含[RFC6125]中指定的DNS-ID。这是将出现在用于验证数据库的证书的主题字段中的名称。数据库名称的用途是允许使用多个数据库。这些数据库将由路由器合并。重要的是，EID到RLOC的映射只能在一个数据库中列出，以免出现不一致。但是，可以将映射从一个数据库转换到另一个数据库。在过渡期间，映射将是相同的。否则，结果行为将是未定义的。数据库名称用空值填充到最接近的第四个字节。
The PKCS#7 [RFC2315] authentication block contains a DER-encoded [ITU.X509.2000] signature and associated public key. For the purposes of this experiment, all implementations will support the RSA encryption signature algorithm and SHA1 digest algorithm, and the standard attributes are expected to be present.
PKCS#7[RFC2315]认证块包含DER编码的[ITU.X509.2000]签名和相关公钥。出于本实验的目的，所有实现都将支持RSA加密签名算法和SHA1摘要算法，并且预计将提供标准属性。
N.B., it has been suggested that the Cryptographic Message Syntax (CMS) [RFC5652] be used instead of PKCS#7. At the time this experiment was performed, CMS was not yet widely deployed. However, it is certainly the correct direction and should be strongly considered in future related work.
注意，有人建议使用加密消息语法（CMS）[RFC5652]代替PKCS#7。在进行该实验时，CMS尚未广泛部署。但是，这肯定是正确的方向，应该在今后的相关工作中予以大力考虑。
As distributed over the network, NERD records appear as follows:
通过网络分发，NERD记录如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num. RLOCs | EID Pref. Len | EID AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 1 | Weight 1 | AFI 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 2 | Weight 2 | AFI 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 3 | Weight 3 | AFI 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 3... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num. RLOCs | EID Pref. Len | EID AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 1 | Weight 1 | AFI 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 2 | Weight 2 | AFI 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 3 | Weight 3 | AFI 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 3... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EID AFI is the AFI of the EID. Priority N, Weight N, and AFI N are associated with Routing Locator N. There will always be at least one RLOC. The minimum record size for IPv4 is 16 bytes. Each additional IPv4 RLOC increases the record size by 8 bytes. The purpose of this format is to keep the database compact, but somewhat easily read. The meaning of weight and priority are described in [RFC6830]. The format of the AFI is specified by IANA in the "Address Family Numbers" registry, with the exception of how IPv6 EID-Prefixes are stored.
EID AFI是EID的AFI。优先级N、权重N和AFI N与路由定位器N相关联。将始终至少有一个RLOC。IPv4的最小记录大小为16字节。每增加一个IPv4 RLOC，记录大小就会增加8个字节。这种格式的目的是保持数据库紧凑，但有点容易读取。[RFC6830]中描述了权重和优先级的含义。AFI的格式由IANA在“地址系列号”注册表中指定，但IPv6 EID前缀的存储方式除外。
NERD assumes that EIDs stored in the database are prefixes, and therefore are accompanied with prefix lengths. In order to reduce storage and transmission amounts for IPv6, only the necessary number of bytes of an EID as specified by the prefix length are kept in the record, rounded to the nearest 4-byte (word) boundary. For instance, if the prefix length is /49, the nearest 4-byte word boundary would require that 8 bytes are stored. IPv6 RLOCs are represented as normal 128-bit IPv6 addresses.
NERD假设存储在数据库中的EID是前缀，因此带有前缀长度。为了减少IPv6的存储和传输量，记录中只保留由前缀长度指定的EID的必要字节数，四舍五入到最近的4字节（字）边界。例如，如果前缀长度为/49，则最近的4字节字边界需要存储8个字节。IPv6 RLOC表示为正常的128位IPv6地址。
A database update contains a set of changes to an existing database. Each {AFI, EID, mask-length} tuple may have zero or more RLOCs associated with it. In the case where there are no RLOCs, the EID entry is removed from the database. Records that contain EIDs and prefix lengths that were not previously listed are simply added. Otherwise, the old record for the EID and prefix length is replaced by the more current information. The record format used by the database update is the same as described in Section 3.1.
数据库更新包含对现有数据库的一组更改。每个{AFI，EID，mask length}元组可以有零个或多个与之关联的RLOC。在没有RLOCs的情况下，将从数据库中删除EID条目。只需添加包含先前未列出的EID和前缀长度的记录。否则，EID和前缀长度的旧记录将替换为更新的信息。数据库更新使用的记录格式与第3.1节中所述的相同。
Bootstrap occurs when a router needs to retrieve the entire database. It knows it needs to retrieve the entire database because either it has none or it has an update too substantial to process, as might be the case if a router has been out of service for a substantially lengthy period of time.
当路由器需要检索整个数据库时，会发生引导。它知道它需要检索整个数据库，因为要么它没有数据库，要么它有一个无法处理的更新，这可能是因为路由器已经停止服务很长一段时间了。
To bootstrap, the ITR appends the database name plus "/current/ entiredb" to a base distribution URI and retrieves the file via HTTP. More formally (using ABNF from [RFC5234]):
为了引导，ITR将数据库名加上“/current/entiredb”附加到基本分发URI，并通过HTTP检索文件。更正式地说（使用[RFC5234]中的ABNF）：
entire-db = base-uri dbname "/current/entiredb"
base-uri = uri ; from RFC 3986
dbname = DNS-ID ; from RFC 6125
entire-db = base-uri dbname "/current/entiredb"
base-uri = uri ; from RFC 3986
dbname = DNS-ID ; from RFC 6125
For example, if the base distribution URI is "http://www.example.com/eiddb/", and assuming a database name of "nerd.arin.net", the ITR would request "http://www.example.com/eiddb/nerd.arin.net/current/entiredb". Routers check the signature on the database prior to installing it, and they check that the database schema matches a schema they understand. Once a router has a valid database, it stores that database in some sort of non-volatile memory (e.g., disk, flash memory, etc).
例如，如果基本分发URI为“http://www.example.com/eiddb/，并假设数据库名为“nerd.arin.net”，ITR将请求http://www.example.com/eiddb/nerd.arin.net/current/entiredb". 路由器在安装数据库之前检查其签名，并检查数据库模式是否与他们理解的模式匹配。一旦路由器拥有一个有效的数据库，它就会将该数据库存储在某种非易失性内存（例如磁盘、闪存等）中。
N.B., the host component for such URIs should not resolve to a LISP EID, lest a circular dependency be created.
注意，此类URI的主机组件不应解析为LISP EID，以免创建循环依赖关系。
In order to retrieve a set of database changes, an ITR will have previously retrieved the entire database. Hence, it knows the current version of the database it has. Its first step for retrieving changes is to retrieve the current version number of the
为了检索一组数据库更改，ITR以前会检索整个数据库。因此，它知道它拥有的数据库的当前版本。检索更改的第一步是检索当前版本号
database. It does so by appending "/current/version" to the base distribution URI and database name and retrieving the file. Its format is text, and it contains the integer value of the current database version.
数据库它通过将“/current/version”附加到基本分发URI和数据库名称并检索文件来实现。其格式为文本，包含当前数据库版本的整数值。
Once an ITR has retrieved the current version, it compares the version of its local copy. If there is no difference, then the router is up to date and need take no further actions until it next checks.
ITR检索到当前版本后，将比较其本地副本的版本。如果没有差异，则路由器是最新的，在下次检查之前不需要采取进一步的操作。
If the versions differ, the router next sends a request for the appropriate change file by appending "current/changes/" and the textual representation of the version of its local copy of the database to the base distribution URI. More formally:
如果版本不同，路由器接下来通过将“current/changes/”及其数据库本地副本版本的文本表示形式附加到基本分发URI来发送对适当更改文件的请求。更正式地说：
db-version = base-uri dbname "/current/version"
db-curupdate = base-uri dbname "/current/changes/" old-version
old-version = 1*DIGIT
db-version = base-uri dbname "/current/version"
db-curupdate = base-uri dbname "/current/changes/" old-version
old-version = 1*DIGIT
For example, if the current version of the database is 1105503, the router's version is 1105500, and the base URI and database name are the same as above, the router would first request "http://www.example.com/eiddb/nerd.arin.net/current/version" to determine that it is out of date, and also to learn the current version. It would then attempt to retrieve "http://www.example.com/eiddb/nerd.arin.net/current/changes/1105500".
例如，如果数据库的当前版本为1105503，路由器的版本为1105500，并且基本URI和数据库名称与上述相同，则路由器将首先请求“http://www.example.com/eiddb/nerd.arin.net/current/version“以确定它已过时，并了解当前版本。然后它将尝试检索“http://www.example.com/eiddb/nerd.arin.net/current/changes/1105500".
The server may not have that change file, either because there are too many versions between what the router has and what is current or because no such change file was generated. If the server has changes from the router's version to any later version, the server issues an HTTP redirect to that change file, and the router retrieves and processes it. More formally:
服务器可能没有该更改文件，这可能是因为路由器的版本与当前版本之间的版本太多，或者是因为没有生成此类更改文件。如果服务器有从路由器版本到任何更高版本的更改，服务器将向该更改文件发出HTTP重定向，路由器将检索并处理该更改文件。更正式地说：
db-incupdate = base-uri dbname "/" newer-version
"/changes/" old-version
newer-version = 1*DIGIT
db-incupdate = base-uri dbname "/" newer-version
"/changes/" old-version
newer-version = 1*DIGIT
For example:
例如：
"http://www.example.com/eiddb/nerd.arin.net/1105450/changes/1105401" would update a router from version 1105401 to 1105450. Once it has done so, the router should then repeat the process until it has brought itself up to date.
"http://www.example.com/eiddb/nerd.arin.net/1105450/changes/1105401“将路由器从版本1105401更新为1105450。一旦这样做了，路由器就应该重复这个过程，直到它自己更新。
This begs the question: how does a router know to retrieve version 1105450 in our example above? It cannot. A redirect must be given by the server to that URI when the router attempts to retrieve differences from the current version, say, 1105503.
这就引出了一个问题：在上面的示例中，路由器如何知道检索版本1105450？它不能。当路由器试图检索与当前版本（例如1105503）的差异时，服务器必须向该URI提供重定向。
While it is unlikely that database versions would wrap, as they consist of 32-bit integers, should the event occur, ITRs should attempt first to retrieve a change file when their current version number is within 10,000 of 2^32 and they see a version available that is less than 10,000. Barring the availability of a change file, the ITR can still assume that the database version has wrapped and retrieve a new copy. It may be safer in future work to include additional wrap information or a larger field to avoid having to use any heuristics.
虽然在事件发生时，数据库版本不太可能被包装，因为它们由32位整数组成，但当它们的当前版本号在2^32的10000范围内，并且它们看到的可用版本小于10000时，ITRs应首先尝试检索更改文件。除非更改文件可用，否则ITR仍然可以假定数据库版本已包装并检索新副本。在未来的工作中，包括额外的包装信息或更大的字段可能更安全，以避免使用任何启发式方法。
We will start our analysis by looking at how much data will be transferred to a router during bootstrap conditions. We will then look at the bandwidth required. Next, we will turn our concerns to servers. Finally, we will ponder the effect of providing only changes.
我们将通过观察在引导条件下将有多少数据传输到路由器来开始分析。然后我们将查看所需的带宽。接下来，我们将关注服务器。最后，我们将考虑只提供更改的效果。
In the analysis below, we treat the overhead of the database header as insignificant (because it is). The analysis should be similar, whether a single database or multiple databases are employed, as we would assume that no entry would appear more than once.
在下面的分析中，我们将数据库头的开销视为无关紧要的（因为它很重要）。无论使用单个数据库还是多个数据库，分析都应该是类似的，因为我们假设没有条目会出现一次以上。
By its very nature, the information to be transported is relatively static and is specifically designed to be topologically insensitive. That is, every ITR is intended to have the same set of RLOCs for a given EID. While some processing power will be necessary to install a table, the amount required should be far less than that of a routing information database because the level of entropy is intended to be lower.
就其本质而言，要传输的信息是相对静态的，并且专门设计为对拓扑不敏感。也就是说，对于给定的EID，每个ITR都有相同的RLOC集。虽然安装一个表需要一些处理能力，但所需的处理能力应该远远低于路由信息数据库，因为熵的级别将更低。
For purposes of this analysis, we will assume that the world has migrated to IPv6, as this increases the size of the database, which would be our primary concern. However, to mitigate the size increase, we have limited the size of the prefix transmitted. For purposes of this analysis, we shall assume an average prefix length of 64 bits.
出于本分析的目的，我们将假设世界已经迁移到IPv6，因为这会增加数据库的大小，这将是我们主要关注的问题。但是，为了减少大小的增加，我们限制了所传输前缀的大小。为了进行此分析，我们将假定平均前缀长度为64位。
Based on that assumption, Section 3.1 states that mapping information for each EID/prefix includes a group of RLOCs, each with an associated priority and weight, and that a minimum record size with IPv6 EIDs with at least one RLOC is 30 bytes uncompressed. Each additional IPv6 RLOC costs 20 bytes.
基于该假设，第3.1节指出，每个EID/前缀的映射信息包括一组RLOC，每个RLOC具有相关的优先级和权重，并且具有至少一个RLOC的IPv6 EID的最小记录大小为30字节未压缩。每增加一个IPv6 RLOC需要20字节。
+-----------+--------+--------+---------+
| 10^n EIDs | 2 RLOC | 4 RLOC | 8 RLOC |
+-----------+--------+--------+---------+
| 4 | 500 KB | 900 KB | 1.70 MB |
| 5 | 5.0 MB | 9.0 MB | 17.0 MB |
| 6 | 50 MB | 90 MB | 170 MB |
| 7 | 500 MB | 900 MB | 1.70 GB |
| 8 | 5.0 GB | 9.0 GB | 17.0 GB |
+-----------+--------+--------+---------+
+-----------+--------+--------+---------+
| 10^n EIDs | 2 RLOC | 4 RLOC | 8 RLOC |
+-----------+--------+--------+---------+
| 4 | 500 KB | 900 KB | 1.70 MB |
| 5 | 5.0 MB | 9.0 MB | 17.0 MB |
| 6 | 50 MB | 90 MB | 170 MB |
| 7 | 500 MB | 900 MB | 1.70 GB |
| 8 | 5.0 GB | 9.0 GB | 17.0 GB |
+-----------+--------+--------+---------+
Table 1: Database size for IPv6 routes with average prefix length of 64 bits
表1：平均前缀长度为64位的IPv6路由的数据库大小
Entries in the above table are derived as follows:
上表中的条目推导如下：
E * (30 + 20 * (R - 1 ))
E * (30 + 20 * (R - 1 ))
where E = number of EIDs (10^n), R = number of RLOCs per EID.
其中E=EID的数量（10^n），R=每个EID的RLOC数量。
Our scaling target is to accommodate 10^8 multihomed systems, which is one order of magnitude greater than what is discussed in [CARP07]. At 10^8 entries, a device could be expected to use between 5 and 17 GB of RAM for the mapping. No matter the method of distribution, any router that sits in the core of the Internet would require near this amount of memory in order to perform the ITR function. Large-enterprise ETRs would be similarly strained, simply due to the diversity of sites that communicate with one another. The good news is that this is not our starting point, but rather our scaling target, a number that we intend to reach by the year 2050. Our starting point is more likely in the neighborhood of 10^4 or 10^5 EIDs, thus requiring between 500 KB and 17 MB.
我们的扩展目标是容纳10^8个多宿系统，这比[CAP07]中讨论的要大一个数量级。在10^8个条目时，设备可能会使用5到17 GB的RAM进行映射。无论采用何种分发方式，位于互联网核心的任何路由器都需要接近此容量的内存才能执行ITR功能。大型企业ETR也将面临类似的压力，这仅仅是由于相互通信的站点的多样性。好消息是，这不是我们的起点，而是我们的规模目标，我们打算在2050年达到这个数字。我们的起点更可能在10^4或10^5 EID附近，因此需要500 KB到17 MB。
+-------------------+---------+---------+----------+--------+
| Table Size (10^n) | 1 MB/s | 10 MB/s | 100 MB/s | 1 GB/s |
+-------------------+---------+---------+----------+--------+
| 6 | 8 | 0.8 | 0.08 | 0.008 |
| 7 | 80 | 8 | 0.8 | 0.08 |
| 8 | 800 | 80 | 8 | 0.8 |
| 9 | 8,000 | 800 | 80 | 8 |
| 10 | 80,000 | 8,000 | 800 | 80 |
| 11 | 800,000 | 80,000 | 8,000 | 800 |
+-------------------+---------+---------+----------+--------+
+-------------------+---------+---------+----------+--------+
| Table Size (10^n) | 1 MB/s | 10 MB/s | 100 MB/s | 1 GB/s |
+-------------------+---------+---------+----------+--------+
| 6 | 8 | 0.8 | 0.08 | 0.008 |
| 7 | 80 | 8 | 0.8 | 0.08 |
| 8 | 800 | 80 | 8 | 0.8 |
| 9 | 8,000 | 800 | 80 | 8 |
| 10 | 80,000 | 8,000 | 800 | 80 |
| 11 | 800,000 | 80,000 | 8,000 | 800 |
+-------------------+---------+---------+----------+--------+
Table 2: Number of seconds to process NERD
表2：处理NERD的秒数
The length of time it takes to receive the database is significant in models where the device acquires the entire table. During this period of time, either the router will be unable to route packets using LISP or it must use some sort of query mechanism for specific EIDs as it populates the rest of its table through the transfer. Table 2 shows us that at our scaling target, the length of time it would take for a router using 1 MB/s of bandwidth is about 80 seconds. We can measure the processing rate in small numbers of hours for any transfer speed greater than that. The fastest processing time shows us as taking 8 seconds to process an entire table of 10^9 bytes and 80 seconds for 10^10 bytes.
在设备获取整个表的模型中，接收数据库所需的时间非常长。在此期间，路由器将无法使用LISP路由数据包，或者在通过传输填充其表的其余部分时，必须对特定EID使用某种查询机制。表2显示，在我们的扩展目标下，使用1 MB/s带宽的路由器所需的时间约为80秒。对于任何大于该值的传输速度，我们都可以在少量小时内测量处理速度。最快的处理时间表明，处理10^9字节的整个表需要8秒，处理10^10字节需要80秒。
As easy as it may be for a router to retrieve, the aggregate information may be difficult for servers to transmit, assuming the information is transmitted in aggregate (we'll revisit that assumption later).
对于路由器来说，检索聚合信息可能很容易，但如果信息以聚合方式传输，那么服务器可能很难传输聚合信息（我们稍后将重新讨论该假设）。
+----------------+------------+-----------+------------+------------+
| # Simultaneous | 10 Servers | 100 | 1,000 | 10,000 |
| Requests | | Servers | Servers | Servers |
+----------------+------------+-----------+------------+------------+
| 100 | 720 | 72 | 72 | 72 |
| 1,000 | 7,200 | 720 | 72 | 72 |
| 10,000 | 72,000 | 7,200 | 720 | 72 |
| 100,000 | 720,000 | 72,000 | 7,200 | 720 |
| 1,000,000 | 7,200,000 | 720,000 | 72,000 | 7,200 |
| 10,000,000 | 72,000,000 | 7,200,000 | 720,000 | 72,000 |
+----------------+------------+-----------+------------+------------+
+----------------+------------+-----------+------------+------------+
| # Simultaneous | 10 Servers | 100 | 1,000 | 10,000 |
| Requests | | Servers | Servers | Servers |
+----------------+------------+-----------+------------+------------+
| 100 | 720 | 72 | 72 | 72 |
| 1,000 | 7,200 | 720 | 72 | 72 |
| 10,000 | 72,000 | 7,200 | 720 | 72 |
| 100,000 | 720,000 | 72,000 | 7,200 | 720 |
| 1,000,000 | 7,200,000 | 720,000 | 72,000 | 7,200 |
| 10,000,000 | 72,000,000 | 7,200,000 | 720,000 | 72,000 |
+----------------+------------+-----------+------------+------------+
Table 3: Retrieval time per number of servers in seconds
表3：每台服务器的检索时间（秒）
This assumes an average of 10^8 entries with 4 RLOCs per EID and that each server has access to 1 GB/s, 100% efficient use of that bandwidth, and no compression.
这假设平均每个EID有10^8个条目和4个RLOC，并且每个服务器都可以访问1 GB/s，该带宽的利用率为100%，并且没有压缩。
Entries in the above table were generated using the following method:
上表中的条目是使用以下方法生成的：
For 10^8 entries with four RLOCs per EID, the table size is 9.0 GB, per our previous table. Assume 1 GB/s transfer rates and 100% utilization. Protocol overhead is ignored for this exercise. Hence, a single transfer X takes 48 seconds and can get no faster.
对于每个EID有四个RLOC的10^8个条目，根据我们之前的表，表大小为9.0 GB。假设传输速率为1 GB/s，利用率为100%。此练习忽略协议开销。因此，单次传输X需要48秒，并且不会更快。
With this in mind, each entry is as follows:
考虑到这一点，每个条目如下：
max(1X,N*X/S)
max(1X,N*X/S)
where N = number of transfers, X = 72 seconds, and S = number of servers.
其中N=传输次数，X=72秒，S=服务器数量。
If we have a distribution model in which every device must retrieve the mapping information upon start, Table 3 shows the length of time in seconds it will take for a given number of servers to complete a transfer to a given number of devices. This table says, as an example, that it would take 72,000 seconds (20 hours) for 1,000,000 ITRs to simultaneously retrieve the database from 1,000 servers, assuming equal load distribution. Should a cold-start scenario occur, this number should be of some concern. Hence, it is important to take some measures both to avoid such a scenario and to ease the load should it occur. The primary defense should be for ITRs to first attempt to retrieve their databases from their peers or upstream providers. Secondary defenses could include data sanity checks within ITRs, with agreed norms for how much the database should change in any given update or over any given period of time. As we will see below, dissemination of changes is considerably less volume.
如果我们有一个分布模型，其中每个设备在启动时都必须检索映射信息，那么表3显示了给定数量的服务器完成到给定数量的设备的传输所需的时间长度（以秒为单位）。例如，此表表示，假设负载分布相等，1000000 ITR同时从1000台服务器检索数据库需要72000秒（20小时）。如果出现冷启动情况，这个数字应该引起一些关注。因此，采取一些措施来避免这种情况，并在出现这种情况时减轻负载，这一点很重要。主要防御措施应该是ITR首先尝试从其对等方或上游提供商检索其数据库。二级防御措施可能包括ITRs内的数据健全性检查，以及在任何给定更新或在任何给定时间段内数据库应更改多少的约定规范。正如我们将在下面看到的，变化的传播量要小得多。
+----------------+-------------+---------------+----------------+
| % Daily Change | 100 Servers | 1,000 Servers | 10,000 Servers |
+----------------+-------------+---------------+----------------+
| 0.1% | 300 | 30 | 3 |
| 0.5% | 1,500 | 150 | 15 |
| 1% | 3,000 | 300 | 30 |
| 5% | 15,000 | 1,500 | 150 |
| 10% | 30,000 | 3,000 | 300 |
+----------------+-------------+---------------+----------------+
+----------------+-------------+---------------+----------------+
| % Daily Change | 100 Servers | 1,000 Servers | 10,000 Servers |
+----------------+-------------+---------------+----------------+
| 0.1% | 300 | 30 | 3 |
| 0.5% | 1,500 | 150 | 15 |
| 1% | 3,000 | 300 | 30 |
| 5% | 15,000 | 1,500 | 150 |
| 10% | 30,000 | 3,000 | 300 |
+----------------+-------------+---------------+----------------+
Table 4: Transfer times for hourly updates, shown in seconds
表4：每小时更新的传输时间，以秒为单位
Assuming 10 million routers and a database size of 9 GB, resulting transfer times for hourly updates are shown in seconds, given number of servers and daily rate of change. Note that when insufficient resources are devoted to servers, an unsustainable situation arises where updates for the next batch would begin prior to the completion of the current batch.
假设1000万路由器和9GB的数据库大小，每小时更新的传输时间以秒为单位显示，给定服务器数量和每日变化率。请注意，当用于服务器的资源不足时，会出现不可持续的情况，即下一批的更新将在当前批完成之前开始。
This table shows us that with 10,000 servers the average transfer time with 1 GB/s links for 10,000,000 routers will be 300 seconds with 10% daily change spread over 24 hourly updates. For a 0.1% daily change, that number is 3 seconds for a database of size 9.0 GB.
此表显示，对于10000台服务器，10000000台路由器在1 GB/s链路下的平均传输时间为300秒，每天10%的变化分布在24小时的更新中。对于每天0.1%的更改，对于大小为9.0 GB的数据库，该数字为3秒。
The amount of change goes to the purpose of LISP. If its purpose is to provide effective multihoming support to end customers, then we might anticipate relatively few changes. If, on the other hand, service providers attempt to make use of LISP to provide some form of traffic engineering, we can expect the same data to change more often. We cannot conclude much in this regard without additional operational experience. The one thing we can say is that different applications of LISP may require new and different distribution mechanisms. Such optimization is left for another day.
更改的数量符合LISP的目的。如果其目的是为最终客户提供有效的多主机支持，那么我们可能预期的变化相对较少。另一方面，如果服务提供商试图利用LISP提供某种形式的流量工程，我们可以预期相同的数据会更频繁地更改。在这方面，如果没有更多的运作经验，我们无法得出很多结论。我们可以说的一点是，LISP的不同应用可能需要新的和不同的分发机制。这样的优化留待以后进行。
If an attacker can forge an update or tamper with the database, he can in effect redirect traffic to end sites. Hence, integrity and authenticity of the NERD is critical. In addition, a means is required to determine whether a source is authorized to modify a given database. No data privacy is required. Quite to the contrary, this information will be necessary for any ITR.
如果攻击者可以伪造更新或篡改数据库，他实际上可以将流量重定向到终端站点。因此，书呆子的完整性和真实性至关重要。此外，还需要一种方法来确定源是否有权修改给定的数据库。不需要数据隐私。恰恰相反，任何ITR都需要这些信息。
The first question one must ask is who to trust to provide the ITR a mapping. Ultimately, the owner of the EID-Prefix is most authoritative for the mapping to RLOCs. However, were all owners to sign all such mappings, ITRs would need to know which owner is authorized to modify which mapping, creating a problem of O(N^2) complexity.
我们必须问的第一个问题是，应该信任谁来提供ITR a映射。最终，EID前缀的所有者对于映射到RLOCs是最权威的。但是，如果所有所有者都要签署所有此类映射，ITRs将需要知道哪个所有者有权修改哪个映射，从而产生O（N^2）复杂性问题。
We can reduce this problem substantially by investing some trust in a small number of entities that are allowed to sign entries. If an authority manages EIDs much the same way a domain name registrar handles domains, then the owner of the EID would choose a database authority she or he trusts, and ITRs must trust each such authority in order to map the EIDs listed by that authority to RLOCs. This reduces the amount of management complexity on the ETR to retaining knowledge of O(# authorities), but does require that each authority establish procedures for authenticating the owner of an EID. Those procedures needn't be the same.
我们可以通过对少数允许签署条目的实体投资一些信任，从而大大减少这个问题。如果机构管理EID的方式与域名注册机构处理域的方式大致相同，则EID的所有者将选择她或他信任的数据库机构，ITRs必须信任每个此类机构，以便将该机构列出的EID映射到RLOC。这降低了ETR的管理复杂性，从而保留了O（#机构）的知识，但要求每个机构建立认证EID所有者的程序。这些程序不必相同。
There are two classic methods to ensure integrity of data:
有两种经典方法可确保数据的完整性：
o secure transport of the source of the data to the consumer, such as Transport Layer Security (TLS) [RFC5246]; and
o 将数据源安全传输到使用者，如传输层安全（TLS）[RFC5246]；和
o provide object-level security.
o 提供对象级安全性。
These methods are not mutually exclusive, although one can argue about the need for the former, given the latter.
这些方法并不是相互排斥的，尽管考虑到后者，人们可以争论是否需要前者。
In the case of TLS, when it is properly implemented, the objects being transported cannot easily be modified by interlopers or so-called men in the middle. When data objects are distributed to multiple servers, each of those servers must be trusted. As we have seen above, we could have quite a large number of servers, thus providing an attacker a large number of targets. We conclude that some form of object-level security is required.
在TLS的情况下，当它被正确地实施时，被运输的对象不能很容易地被中间人或所谓中间人修改。当数据对象分布到多个服务器时，必须信任这些服务器中的每一个。如上所述，我们可能拥有大量服务器，从而为攻击者提供大量目标。我们得出结论，需要某种形式的对象级安全性。
Object-level security involves an authority signing an object in a way that can easily be verified by a consumer, e.g., a router. In this case, we would want the mapping table and any incremental update to be signed by the originator of the update. This implies that we cannot simply make use of a tool like CVS [CVS]. Instead, the originator will want to generate diffs, sign them, and make them available either directly or through some sort of content distribution or peer to peer network.
对象级安全性涉及授权机构以消费者（例如路由器）可以轻松验证的方式对对象进行签名。在这种情况下，我们希望映射表和任何增量更新都由更新的发起人签名。这意味着我们不能简单地使用像CVS[CVS]这样的工具。取而代之的是，发起者希望生成差异，对其进行签名，并直接或通过某种内容分发或点对点网络使其可用。
X.509 provides a certificate hierarchy that has scaled to the size of the Internet. The system is most manageable when there are few certificates to manage. The model proposed in this memo makes use of one current certificate per database authority. The two pieces of information necessary to verify a signature, therefore, are as follows:
X.509提供了一个已扩展到Internet大小的证书层次结构。当需要管理的证书很少时，系统最易于管理。本备忘录中提出的模型为每个数据库授权使用一个当前证书。因此，验证签名所需的两条信息如下：
o the certificate of the database authority, which can be provided along with the database; and
o 数据库管理机构的证书，可随数据库一起提供；和
o the certificate authority's certificate.
o 证书颁发机构的证书。
The latter two pieces of information must be very well known and must be configured on each ITR. It is expected that both would change very rarely, and it would not be unreasonable for such updates to occur as part of a normal OS release process.
后两条信息必须是众所周知的，并且必须在每个ITR上进行配置。预计两者都很少发生变化，而且作为正常操作系统发布过程的一部分进行此类更新也不是不合理的。
The tools for both signing and verifying are readily available. OpenSSL (http://www.openssl.org) provides tools and libraries for both signing and verifying. Other tools commonly exist.
用于签名和验证的工具随时可用。OpenSSL(http://www.openssl.org)提供用于签名和验证的工具和库。其他工具也普遍存在。
Use of PKIs is not without implementation complexity, operational complexity, or risk. The following risks and mitigations are identified with NERD's use of PKIs:
PKI的使用并非没有实现复杂性、操作复杂性或风险。NERD使用PKI时确定了以下风险和缓解措施：
The private key of a NERD authority is exposed: In this case, an attacker could sign a false database update, either redirecting traffic or otherwise causing havoc. The NERD administrator must revoke its existing key and issue a new one. The certificate is added to a certificate revocation list (CRL), which may be distributed with both this and other databases, as well as through other channels. Because this event is expected to be rare, and the number of database authorities is expected to be small, a CRL will be small. When a router receives a revocation, it checks it against its existing databases, and attempts to update the one that is revoked. This implies that prior to issuing the revocation, the database authority would sign an update with the new key. Routers would discard updates they have already received that were signed after the revocation was generated. If a router cannot confirm whether the authority's certificate was revoked before or after a particular update, it will retrieve a fresh new copy of the database with a valid signature.
NERD权威机构的私钥被公开：在这种情况下，攻击者可能会签署错误的数据库更新，从而重定向流量或造成严重破坏。NERD管理员必须撤销其现有密钥并颁发新密钥。证书被添加到证书吊销列表（CRL）中，该列表可以与此数据库和其他数据库一起分发，也可以通过其他渠道分发。由于此事件预计将非常罕见，并且数据库权限的数量预计很小，因此CRL将很小。当路由器收到撤销时，它会根据其现有数据库检查撤销，并尝试更新被撤销的数据库。这意味着在发出撤销之前，数据库管理机构将使用新密钥签署更新。路由器将丢弃已收到的更新，这些更新是在生成撤销后签署的。如果路由器无法确认授权机构的证书是在特定更新之前还是之后被吊销，它将检索具有有效签名的数据库的新副本。
The private key associated with a CA in the chain of trust of the Authority's certificate is compromised: In this case, it becomes possible for an attacker to masquerade as the database authority. To ameliorate damage, the database authority revokes its certificate and get a new certificate issued from a CA that is not compromised. Once it has done so, the previous procedure is followed. The compromised certificate can be removed during the normal OS upgrade cycle. In the case of the root authority, the situation could be more serious. Updates to the OS in the ITR need to be validated prior to installation. One possible method of doing this is provided in [RFC4108]. Trust anchors are assumed to be updated as part of an OS update; implementors should consider using a key other than the trust anchor for validating OS updates.
与授权机构证书信任链中的CA相关联的私钥被泄露：在这种情况下，攻击者有可能伪装成数据库授权机构。为了减轻损害，数据库管理机构撤销了其证书，并从未受损害的CA处获得新证书。完成此操作后，将遵循前面的步骤。在正常操作系统升级周期中，可以删除受损证书。就基层当局而言，情况可能更为严重。ITR中的操作系统更新需要在安装之前进行验证。[RFC4108]中提供了一种可能的方法。信任锚被认为是OS更新的一部分；实现者应该考虑使用信任锚以外的密钥来验证OS更新。
An algorithm used if either the certificate or the signature is cracked: This is a catastrophic failure and the above forms of attack become possible. The only mitigation is to make use of a new algorithm. In theory, this should be possible, but in practice it has proved very difficult. For this reason, additional work is recommended to make alternative algorithms available.
当证书或签名被破解时使用的一种算法：这是一种灾难性的失败，上述形式的攻击成为可能。唯一的缓解措施是使用新算法。在理论上，这应该是可能的，但在实践中，这已经证明是非常困难的。因此，建议进行额外的工作，以提供替代算法。
The NERD authority loses its key or disappears: In this case, nobody can update the existing database. There are few programmatic mitigations. If the database authority places its private keys and suitable amounts of information in escrow, under agreed upon circumstances (for example, no updates for three days), the escrow agent would release the information to a party competent of generating a database update.
NERD权威机构丢失了它的密钥或者消失了：在这种情况下，没有人可以更新现有的数据库。很少有计划性的缓解措施。如果数据库管理局在约定的情况下（例如，三天内没有更新），将其私钥和适当数量的信息置于托管中，托管代理将向有权生成数据库更新的一方发布信息。
Because this specification does not require secure transport, if an attacker prevents updates to an ITR for the purposes of having that ITR continue to use a compromised ETR, the ITR could continue to use an old version of the database without realizing a new version has been made available. If one is worried about such an attack, a secure channel (such as SSL) to a secure chain back to the database authority should be used. It is possible that, after some operational experience, later versions of this format will contain additional semantics to address this attack. SSL would also prevent attempts to spoof false database versions on the server.
由于此规范不需要安全传输，如果攻击者为了让ITR继续使用受损的ETR而阻止对ITR的更新，ITR可能会继续使用旧版本的数据库，而不会意识到新版本已可用。如果有人担心这种攻击，那么应该使用安全通道（如SSL）将安全链连接回数据库授权机构。经过一些操作经验后，此格式的更高版本可能会包含其他语义来解决此攻击。SSL还可以防止在服务器上伪造错误数据库版本的尝试。
As discussed above, substantial risk would be a cold-start scenario. If an attacker found a bug in a common OS that allowed it to erase an ITR's database, and was able to disseminate that bug, the collective ability of ITRs to retrieve new copies of the database could be taxed by collective demand. The remedy to this is for devices to share copies of the database with their peers, thus making each potential requester a potential service.
如上所述，实质性风险将是冷启动情景。如果攻击者在一个普通操作系统中发现一个允许其删除ITR数据库的漏洞，并能够传播该漏洞，则ITR检索数据库新副本的集体能力可能会受到集体需求的影响。对此的补救措施是设备与其对等方共享数据库副本，从而使每个潜在的请求者成为潜在的服务。
Many objects these days are distributed as either XML pages or something derived as XML [W3C.REC-xml11-20040204], such as SOAP [W3C.REC-soap12-part1-20070427] [W3C.REC-soap12-part2-20070427]. Use of such well-known standards allows for high-level tools and library reuse. XML's strength is extensibility. Without a doubt XML would be more extensible than a fixed field database. Why not, then, use these standards in this case? The greatest concern the author had was compactness of the data stream. In as much as this mechanism is
如今，许多对象以XML页面或派生为XML的东西的形式分发[W3C.REC-xml11-20040204]，例如SOAP[W3C.REC-soap12-part1-20070427][W3C.REC-soap12-part2-20070427]。使用这些众所周知的标准可以实现高级工具和库的重用。XML的优势在于可扩展性。毫无疑问，XML将比固定字段数据库更具可扩展性。那么，为什么不在这种情况下使用这些标准呢？作者最关心的是数据流的紧凑性。在这一机制中
used at all in the future, so long as that concern could be addressed, and so long as signatures of the database can be verified, XML probably should be considered.
只要这个问题能够得到解决，只要数据库的签名能够得到验证，XML可能就应该被考虑。
We now consider various different mechanisms. The problem of distributing changes in various databases is as old as databases. The author is aware of two obvious approaches that have been well used in the past. One approach would be the wide distribution of CVS repositories. However, for reasons mentioned in Section 5.4, CVS is insufficient to the task.
现在我们考虑各种不同的机制。在各种数据库中分布更改的问题与数据库一样古老。作者意识到两种明显的方法在过去得到了很好的应用。一种方法是广泛分布CVS存储库。然而，由于第5.4节中提到的原因，CVS不足以完成任务。
The other tried and true approach is the use of periodic updates in the form of messages. The good old Network News Transfer Protocol (NNTP) [RFC3977] itself provides two separate mechanisms (one push and another pull) to provide a coherent update process. This was in fact used to update molecular biology databases [gb91] in the early 1990s. Netnews offers a way to determine whether articles with specified Article-Ids have been received. In the case where the mapping file source of authority wishes to transmit updates, it can sign a change file and then post it into the network. Routers merely need to keep a record of article ids that it has received. Netnews systems have years ago handled far greater volume of traffic than we envision [Usenet]. Initially this is probably overkill, but it may not be so later in this process. Some consideration should be given to a mechanism known to widely distribute vast amounts of data, as instantaneously as either the sender or the receiver wishes.
另一种行之有效的方法是使用消息形式的定期更新。好的旧网络新闻传输协议（NNTP）[RFC3977]本身提供了两个独立的机制（一个推送和另一个拉送），以提供一致的更新过程。事实上，这在20世纪90年代初被用于更新分子生物学数据库[gb91]。Netnews提供了一种确定是否已收到具有指定文章ID的文章的方法。如果映射文件授权源希望传输更新，它可以签署更改文件，然后将其发布到网络中。路由器只需要保存一份它收到的物品ID的记录。几年前，Netnews系统处理的流量远远超过了我们的预期[Usenet]。起初，这可能是过度杀戮，但在这一过程的后期可能并非如此。应该考虑一种已知的机制，该机制可以广泛地分发大量数据，发送方或接收方希望立即分发数据。
To attain an additional level of hierarchy in the distribution network, service providers could retrieve information to their own local servers and configure their routers with the host portion of the above URI.
为了在分销网络中实现额外的层次结构，服务提供商可以将信息检索到自己的本地服务器，并使用上述URI的主机部分配置路由器。
Another possibility would be for providers to establish an agreement on a small set of anycast addresses for use for this purpose. There are limitations to the use of anycast, particularly with TCP. In the midst of a routing flap, an anycast address can become all but unusable. Careful study of such a use as well as appropriate use of HTTP redirects is expected.
另一种可能性是，提供商就用于此目的的一小组选播地址建立协议。anycast的使用有一些限制，尤其是TCP。在路由切换过程中，选播地址可能会变得几乎不可用。我们希望仔细研究这种使用以及HTTP重定向的适当使用。
It has been proposed that a query/response mechanism be used for this information and specifically that the Domain Name System (DNS) [RFC1034] be used. The previous models do not preclude DNS. DNS has the advantage that the administrative lines are well drawn, and that the ID-to-RLOC mapping is likely to appear very close to these
有人建议对该信息使用查询/响应机制，特别是使用域名系统（DNS）[RFC1034]。以前的模型不排除DNS。DNS的优点是管理线画得很好，并且ID到RLOC的映射可能看起来非常接近这些线
boundaries. DNS also has the added benefit that an entire distribution infrastructure already exists. There are, however, some problems that could impact end hosts when intermediate routers make queries, some of which were first pointed out in [RFC1383]:
边界。DNS还有一个额外的好处，即整个分发基础设施已经存在。然而，当中间路由器进行查询时，有一些问题可能会影响终端主机，其中一些问题在[RFC1383]中首先指出：
o Any query mechanism offers an opportunity for a resource attack if an attacker can force the ITR to query for information. In this case, all that would be necessary would be for a "botnet" (a group of computers that have been compromised and used as vehicles to attack others) to ping or otherwise contact via some normal service hosts that sit behind the ETR. If the botnet hosts themselves are behind ETRs, the victim's ITR will need to query for each and every one of them, thus becoming part of a classic reflector attack.
o 如果攻击者可以强制ITR查询信息，则任何查询机制都会提供资源攻击的机会。在这种情况下，所有必要的是“僵尸网络”（一组已被破坏并用作攻击他人的工具的计算机）通过ETR后面的一些正常服务主机进行ping或以其他方式联系。如果僵尸网络主机本身在ETR后面，受害者的ITR将需要查询每一个ETR，从而成为典型反射器攻击的一部分。
o Packets will be delayed at the very least, and probably dropped in the process of a mapping query. This could be at the beginning of a communication, but it will be impossible for a router to conclude with certainty that this is the case.
o 数据包至少会延迟，并且可能会在映射查询过程中丢弃。这可能是在通信开始时，但路由器不可能确定地得出这样的结论。
o The DNS has a backoff algorithm that presumes that applications are making queries prior to the beginning of a communication. This is appropriate for end hosts who know in fact when a communication begins. An end user may not enjoy that a router is waiting seconds for a retry.
o DNS有一个退避算法，该算法假定应用程序在通信开始之前进行查询。这适用于实际上知道通信何时开始的终端主机。终端用户可能不喜欢路由器等待几秒钟的重试。
o While the administrative lines may appear to be correct, the location of name servers may not be. If name servers sit within PI address space, thus requiring LISP to reach, a circular dependency is created. This is precisely where many enterprise name servers sit. The LISP experiment should not predicate its success on relocation of such name servers.
o 虽然管理行可能看起来正确，但名称服务器的位置可能不正确。如果名称服务器位于PI地址空间内，因此需要LISP访问，则会创建循环依赖关系。这正是许多企业名称服务器所在的位置。LISP实验不应将其成功归因于此类名称服务器的重新定位。
Nevertheless, DNS may be able to play a role in providing the enterprise control over the mapping of its EIDs to RLOCs. Posit a new DNS record "EID2RLOC". This record is used by the authority to collect and aggregate mapping information so that it may be distributed through one of the other mechanisms. As an example:
然而，DNS可能能够在企业控制其EID到RLOC的映射方面发挥作用。放置一个新的DNS记录“EID2RLOC”。管理局使用该记录收集和汇总映射信息，以便通过其他机制之一分发。例如：
$ORIGIN 0.10.PI-SPACE. 128 EID2RLOC mask 23 priority 10 weight 5 172.16.5.60 EID2RLOC mask 23 priority 15 weight 5 192.168.1.5
$ORIGIN 0.10.PI-SPACE。128 EID2RLOC掩码23优先级10权重5172.16.5.60 EID2RLOC掩码23优先级15权重5192.168.1.5
In the above figure, network 10.0.128/23 would delegated to some end system, say, EXAMPLE.COM. They would manage the above zone information. This would allow a DNS mechanism to work, but it would also allow someone to aggregate the information and distribute a table.
在上图中，网络10.0.128/23将委托给某个终端系统，例如EXAMPLE.COM。他们将管理上述区域信息。这将允许DNS机制工作，但也允许某人聚合信息并分发表。
The Border Gateway Protocol (BGP) [RFC4271] is currently used to distribute inter-domain routing throughout the Internet. Why not, then, use BGP to distribute mapping entries, or provide a rendezvous mechanism to initialize mapping entries? In fact, this is precisely what LISP Alternative Topology (LISP+ALT) [RFC6836] accomplishes, using a completely separate topology from the normal DFZ. It does so using existing code paths and expertise. The alternative topology also provides an extremely accurate control path from ITRs to ETRs, whereas NERD's operational model requires an optimistic assumption and control-plane functionality to cycle through unresponsive ETRs in an EID-Prefix's mapping entry. The memory-scaling characteristics of LISP+ALT are extremely attractive because of expected strong aggregation, whereas NERD makes almost no attempt at aggregation.
边界网关协议（BGP）[RFC4271]目前用于在整个互联网上分发域间路由。那么，为什么不使用BGP来分发映射条目，或者提供集合机制来初始化映射条目呢？事实上，这正是LISP Alternative Topology（LISP+ALT）[RFC6836]使用与普通DFZ完全分离的拓扑实现的。它使用现有的代码路径和专业知识来实现这一点。替代拓扑还提供了从ITR到ETR的极其精确的控制路径，而NERD的运行模型需要乐观假设和控制平面功能，以循环通过EID前缀映射条目中的无响应ETR。LISP+ALT的内存扩展特性非常吸引人，因为它具有预期的强聚合，而NERD几乎没有尝试聚合。
A number of key deployment issues are left open. The principle issue is whether it is deemed acceptable for routers to drop packets occasionally while mapping information is being gathered. This should be the subject of future research for ALT, as it was a key design goal of NERD to avoid such a situation.
许多关键部署问题尚未解决。主要问题是，在收集映射信息时，路由器偶尔丢弃数据包是否被认为是可以接受的。这应该是ALT未来研究的主题，因为避免这种情况是NERD的一个关键设计目标。
Perhaps it would be useful to use both a prepopulated database such as NERD and a query mechanism (perhaps LISP+ALT, LISP-CONS [LISP-CONS], or DNS) to determine an EID-to-RLOC mapping. One idea would be to receive a subset of the mappings, say, by taking only the NERD for certain regions. This alleviates the need to drop packets for some subset of destinations under the assumption that one's business is localized to a particular region. If one did not have a local entry for a particular EID, one would then make a query.
也许可以使用预先填充的数据库（如NERD）和查询机制（可能是LISP+ALT、LISP-CONS[LISP-CONS]或DNS）来确定EID到RLOC的映射。一个想法是接收映射的一个子集，比如说，只接收特定区域的NERD。这减轻了在假定业务本地化到特定区域的情况下为某些目的地子集丢弃数据包的需要。如果没有特定EID的本地条目，则会进行查询。
One approach to using DNS to query live would be to periodically walk "interesting" portions of the network, in search of relevant records, and to cache them to non-volatile storage. While preventing resource attacks, the walk itself could be viewed as an attack, if the algorithm was not selective enough about what it thought was interesting. A similar approach could be applied to LISP+ALT or LISP-CONS by forcing a data-driven Map Reply for certain sites.
使用DNS进行实时查询的一种方法是定期遍历网络中“感兴趣”的部分，搜索相关记录，并将它们缓存到非易失性存储器中。在防止资源攻击的同时，如果算法对其认为有趣的内容没有足够的选择性，那么行走本身可以被视为一种攻击。类似的方法也可以应用于LISP+ALT或LISP-CONS，强制对某些站点进行数据驱动的地图回复。
While LISP and NERD are intended as experiments at this point, it is already obvious one must give serious consideration to circular dependencies with regard to the protocols used and the elements within them.
虽然LISP和NERD在这一点上是作为实验的，但显然必须认真考虑与所使用的协议和其中的元素相关的循环依赖性。
In as much as HTTP depends on DNS, either due to the authority section of a URI or to the configured base distribution URI, these same concerns apply. In addition, any HTTP server that itself makes use of Provider-Independent addresses would be a poor choice to distribute the database for these exact same reasons.
在HTTP依赖DNS的情况下，由于URI的权限部分或配置的基本分发URI，这些问题同样适用。此外，出于这些完全相同的原因，任何本身使用独立于提供程序的地址的HTTP服务器分发数据库都是一个糟糕的选择。
One issue with using HTTP is that it is possible that a middlebox of some form, such as a cache, may intercept and process requests. In some cases, this might be a good thing. For instance, if a cache correctly returns a database, some amount of bandwidth is conserved. On the other hand, if the cache itself fails to function properly for whatever reason, end-to-end connectivity could be impaired. For example, if the cache itself depended on the mapping being in place and functional, a cold-start scenario might leave the cache functioning improperly, in turn providing routers no means to update their databases. Some care must be given to avoid such circumstances.
使用HTTP的一个问题是，某种形式的中间盒（如缓存）可能会拦截和处理请求。在某些情况下，这可能是一件好事。例如，如果缓存正确返回数据库，则会节省一些带宽。另一方面，如果缓存本身由于任何原因无法正常工作，则端到端连接可能会受损。例如，如果缓存本身依赖于映射的到位和功能，则冷启动场景可能会使缓存功能不正常，从而使路由器无法更新其数据库。必须注意避免这种情况。
Do we need to discuss reachability in more detail? This was clearly an issue at the IST-RING (Information Science Technologies - Routing in Next Generation) workshop. There are two key issues. First, what is the appropriate architectural separation between the data plane and the control plane? Second, is there some specific way in which NERD impacts the data plane?
我们需要更详细地讨论可达性吗？这显然是IST-RING（信息科学技术-下一代路由）研讨会上的一个问题。有两个关键问题。首先，数据平面和控制平面之间的适当架构分离是什么？第二，书呆子对数据平面的影响有什么具体的方式吗？
Should we specify a (perhaps compressed) tarball that treads a middle ground for the last question, where each update tarball contains both a signature for the update and for the entire database, once the update is applied?
我们是否应该为最后一个问题指定一个（可能是压缩的）tarball，其中在应用更新后，每个更新tarball都包含更新和整个数据库的签名？
Should we compress? In some initial testing of databases with 1, 5, and 10 million IPv4 EIDs and a random distribution of IPv4 RLOCs, the current format in this document compresses down by a factor of between 35% and 36%, using Burrows-Wheeler block sorting text compression algorithm (bzip2). The NERD used random EIDs with prefix lengths varying from 19-29 bits, with probability weighted toward the smaller masks. This only very roughly reflects reality. A better test would be to start with the existing prefixes found in the DFZ.
我们应该压缩吗？在对包含1、5和1000万个IPv4 EID以及随机分布的IPv4 RLOC的数据库进行的一些初始测试中，本文中的当前格式使用Burrows-Wheeler块排序文本压缩算法（bzip2）压缩了35%到36%的系数。NERD使用前缀长度在19-29位之间的随机EID，概率加权到较小的掩码。这只是非常粗略地反映了现实。更好的测试是从DFZ中现有的前缀开始。
This memo has specified a database format, an update format, a URI convention, an update method, and a validation method for EID-to-RLOC mappings. We have shown that beyond the predictions of 10^8 EID-prefix entries, the aggregate database size would likely be at most 17 GB. We have considered the amount of servers to distribute that information, and we have demonstrated the limitations of a simple content distribution network and other well-known mechanisms. The effort required to retrieve a database change amounts to between 3 and 30 seconds of processing time per hour at today's gigabit speeds. We conclude that there is no need for an off-box query mechanism today and that there are distinct disadvantages for having such a mechanism in the control plane.
此备忘录为EID到RLOC映射指定了数据库格式、更新格式、URI约定、更新方法和验证方法。我们已经表明，除了10^8个EID前缀项的预测之外，聚合数据库大小可能最多为17 GB。我们已经考虑了分发该信息的服务器数量，并且已经证明了简单内容分发网络和其他众所周知的机制的局限性。在今天的千兆位速度下，检索数据库更改所需的工作相当于每小时3到30秒的处理时间。我们的结论是，现在不需要开箱即用的查询机制，在控制平面中使用这种机制有明显的缺点。
Beyond this, we have examined alternatives that allow for hybrid models that do use query mechanisms, should our operating assumptions prove overly optimistic. Use of NERD today does not foreclose use of such models in the future, and in fact both models can happily coexist.
除此之外，如果我们的运营假设过于乐观，我们还研究了允许使用查询机制的混合模型的替代方案。今天使用“书呆子”并不能阻止将来使用这类模型，事实上，这两种模型可以愉快地共存。
Since the first draft of this document in 2007, portions of this work have been implemented. Future work should consider the size of fields, such as the version field, as well as key roll-over and revocation issues. As previously noted, CMS is now widely deployed. Current work on DNS-based authentication of named entities [RFC6698] may provide a means to test authorization of a NERD provider to carry a specific prefix.
自2007年本文件初稿以来，部分工作已经完成。未来的工作应该考虑字段的大小，如版本字段，以及密钥翻转和撤销问题。如前所述，CMS现已广泛部署。目前关于命名实体的基于DNS的身份验证[RFC6698]的工作可能提供一种方法来测试NERD提供商携带特定前缀的授权。
We leave to future work how the list of databases is distributed, how BGP can play a role in distributing knowledge of the databases, and how DNS can play a role in aggregating information into these databases.
我们留给未来的工作是如何分布数据库列表，BGP如何在分布数据库知识方面发挥作用，以及DNS如何在将信息聚合到这些数据库中发挥作用。
We also leave to future work whether HTTP is the best protocol for the job, and whether the scheme described in this document is the most efficient. One could easily envision that when applied in high-delay or high-loss environments, a broadcast or multicast method may prove more effective.
我们还将把HTTP是否是这项工作的最佳协议，以及本文档中描述的方案是否是最有效的留给未来的工作。人们可以很容易地想象，当应用于高延迟或高损耗环境时，广播或多播方法可能更有效。
Speaking of multicast, we also leave to future work how multicast is implemented, if at all, either in conjunction or as an extension to this model.
说到多播，我们还将如何实现多播留待将来的工作，如果有的话，可以结合使用，也可以作为此模型的扩展。
Finally, perhaps the most interesting future work would be to understand if and how NERD could be integrated with the LISP mapping server [RFC6833].
最后，也许未来最有趣的工作是了解NERD是否以及如何与LISP映射服务器集成[RFC6833]。
Dino Farinacci, Patrik Faltstrom, Dave Meyer, Joel Halpern, Jim Schaad, Dave Thaler, Mohamed Boucadair, Robin Whittle, Max Pritikin, Scott Brim, S. Moonesamy, and Stephen Farrel were very helpful with their reviews of this work. Thanks also to the participants of the Routing Research Group and the IST-RING workshop held in Madrid in December of 2007 for their incisive comments. The astute will notice a lengthy References section. This work stands on the shoulders of many others' efforts.
Dino Farinaci、Patrik Faltstrom、Dave Meyer、Joel Halpern、Jim Schaad、Dave Thaler、Mohamed Boucadair、Robin Whittle、Max Pritikin、Scott Brim、S.Moonesamy和Stephen Farrel对这项工作的评论非常有帮助。还感谢路由研究小组和2007年12月在马德里举行的IST-RING研讨会的与会者提出了精辟的意见。精明的人会注意到一个冗长的参考章节。这项工作是许多其他人努力的结果。
[ITU.X509.2000] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000.
[ITU.X509.2000]国际电信联盟，“信息技术-开放系统互连-目录：公钥和属性证书框架”，ITU-T建议X.509，ISO标准9594-8，2000年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，2013年1月。
[CARP07] Carpenter, B., "IETF Plenary Presentation: Routing and Addressing: Where we are today", March 2007.
[CARP07]Carpenter，B.，“IETF全体报告：路线和地址：我们今天的位置”，2007年3月。
[CVS] Grune, R., Baalbergen, E., Waage, M., Berliner, B., and J. Polk, "CVS: Concurrent Versions System", November 1985.
[CVS]Grune，R.，Baalbergen，E.，Waage，M.，Berliner，B.，和J.Polk，“CVS:并发版本系统”，1985年11月。
[LISP-CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.
[LISP-CONS]Farinaci，D.，Fuller，V.，和D.Meyer，“LISP-CONS：LISP的内容分发覆盖网络服务”，正在进行的工作，2008年4月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383, December 1992.
[RFC1383]Huitema，C.，“基于DNS的IP路由的实验”，RFC1383，1992年12月。
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2315]Kaliski，B.，“PKCS#7：加密消息语法版本1.5”，RFC 2315，1998年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977]Feather，C.，“网络新闻传输协议（NNTP）”，RFC3977，2006年10月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108]Housley，R.“使用加密消息语法（CMS）保护固件包”，RFC 4108，2005年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，2012年8月。
[RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013.
[RFC6833]Farinaci，D.和V.Fuller，“定位器/ID分离协议（LISP）地图服务器接口”，RFC 6833，2013年1月。
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6836]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/ID分离协议替代逻辑拓扑（LISP+ALT）”，RFC 68362013年1月。
[Usenet] Wikipedia, "Usenet", January 2013, <http://en.wikipedia.org/w/index.php? title=Usenet&oldid=531545312>.
[Usenet]维基百科，“Usenet”，2013年1月<http://en.wikipedia.org/w/index.php? title=Usenet&oldid=531545312>。
[W3C.REC-soap12-part1-20070427] Gudgin, M., Lafon, Y., Moreau, J., Hadley, M., Karmarkar, A., Mendelsohn, N., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part1-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
[W3C.REC-soap12-part1-20070427]Gudgin，M.，Lafon，Y.，Moreau，J.，Hadley，M.，Karmarkar，A.，Mendelsohn，N.，和H.Nielsen，“SOAP版本1.2第1部分：消息传递框架（第二版）”，万维网联盟建议REC-soap12-part1-20070427，2007年4月<http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
[W3C.REC-soap12-part2-20070427] Karmarkar, A., Hadley, M., Mendelsohn, N., Nielsen, H., Lafon, Y., Gudgin, M., and J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part2-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
[W3C.REC-soap12-part2-20070427]Karmarkar，A.，Hadley，M.，Mendelsohn，N.，Nielsen，H.，Lafon，Y.，Gudgin，M.，和J.Moreau，“SOAP版本1.2第2部分：附件（第二版）”，万维网联盟建议REC-soap12-part2-20070427，2007年4月<http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
[W3C.REC-xml11-20040204] Cowan, J., Maler, E., Sperberg-McQueen, C., Paoli, J., Bray, T., and F. Yergeau, "Extensible Markup Language (XML) 1.1", World Wide Web Consortium First Edition REC-xml11-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml11-20040204>.
[W3C.REC-xml11-20040204]Cowan，J.，Maler，E.，Sperberg McQueen，C.，Paoli，J.，Bray，T.，和F.Yergeau，“可扩展标记语言（XML）1.1”，万维网联盟第一版REC-xml11-20040204，2004年2月<http://www.w3.org/TR/2004/REC-xml11-20040204>.
[gb91] Smith, R., Gottesman, Y., Hobbs, B., Lear, E., Kristofferson, D., Benton, D., and P. Smith, "A mechanism for maintaining an up-to-date GenBank database via Usenet", Computer Applications in the Biosciences (CABIOS), April 1991.
[gb91]Smith，R.，Gottesman，Y.，Hobbs，B.，Lear，E.，Kristoferson，D.，Benton，D.，和P.Smith，“通过Usenet维护最新GenBank数据库的机制”，生物科学中的计算机应用（CABIOS），1991年4月。
Appendix A. Generating and Verifying the Database Signature with OpenSSL
附录A.使用OpenSSL生成和验证数据库签名
As previously mentioned, one goal of NERD was to use off-the-shelf tools to both generate and retrieve the database. To many, PKI is magic. This section is meant to provide at least some clarification as to both the generation and verification process, complete with command-line examples. Not included is how you get the entries themselves. We'll assume they exist and that you're just trying to sign the database.
如前所述，NERD的一个目标是使用现成的工具来生成和检索数据库。对许多人来说，PKI是一种魔力。本节旨在提供至少一些关于生成和验证过程的说明，包括命令行示例。不包括是如何获得条目本身的。我们假设它们存在，并且您只是在尝试对数据库进行签名。
To sign the database, to start with, you need a database file that has a database header described in Section 3. Block size should be zero, and there should be no PKCS#7 block at this point. You also need a certificate and its private key with which you will sign the database.
要对数据库进行签名，首先需要一个具有第3节中所述的数据库头的数据库文件。块大小应为零，此时不应存在PKCS#7块。您还需要一个证书及其私钥，用于对数据库进行签名。
The OpenSSL "smime" command contains all the functions we need from this point forth. To sign the database, issue the following command:
OpenSSL“smime”命令包含从现在起我们需要的所有函数。要对数据库进行签名，请发出以下命令：
openssl smime -binary -sign -outform DER -signer yourcert.crt \
-inkey yourcert.key -in database-file -out signature
openssl smime -binary -sign -outform DER -signer yourcert.crt \
-inkey yourcert.key -in database-file -out signature
-binary states that no MIME canonicalization should be performed. -sign indicates that you are signing the file that was given as the argument to -in. The output format (-outform) is binary DER, and your public certificate is provided with -signer along with your key with -inkey. The signature itself is specified with -out.
-二进制声明不应执行MIME规范化-sign表示您正在对作为参数提供给-in的文件进行签名。输出格式（-outform）是二进制DER，您的公共证书由-signer提供，密钥由-inkey提供。签名本身用-out指定。
The resulting file "signature" is then copied into to PKCS#7 block in the database header, its size in bytes is recorded in the PKCS#7 block size field, and the resulting file is ready for distribution to ITRs.
然后将生成的文件“签名”复制到数据库头中的PKCS#7块中，其字节大小记录在PKCS#7块大小字段中，生成的文件准备分发到ITRs。
To verify a database file, first retrieve the PKCS#7 block from the file by copying the appropriate number of bytes into another file, say, "signature". Next, zero this field, and set the block size field to 0. Next use the "smime" command to verify the signature as follows:
要验证数据库文件，首先从文件中检索PKCS#7块，方法是将适当数量的字节复制到另一个文件中，例如“签名”。接下来，将此字段归零，并将“块大小”字段设置为0。接下来使用“smime”命令验证签名，如下所示：
openssl smime -binary -verify -inform DER -content database-file
-out /dev/null -in signature
openssl smime -binary -verify -inform DER -content database-file
-out /dev/null -in signature
OpenSSL will return "Verification OK" if the signature is correct. OpenSSL provides sufficiently rich libraries to accomplish the above within the C programming language with a single pass.
如果签名正确，OpenSSL将返回“验证确定”。OpenSSL提供了足够丰富的库，可以在C编程语言中一次性完成上述任务。
Author's Address
作者地址
Eliot Lear Cisco Systems GmbH Richtistrasse 7 Wallisellen CH-8304 Switzerland
艾略特·李尔思科系统有限公司Richtistrasse 7 Wallisellen CH-8304瑞士
Phone: +41 44 878 9200
EMail: lear@cisco.com
Phone: +41 44 878 9200
EMail: lear@cisco.com