Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6742 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
S. Rose
US NIST
November 2012
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6742 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
S. Rose
US NIST
November 2012
DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)
标识符定位器网络协议（ILNP）的DNS资源记录
Abstract
摘要
This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group.
本说明描述了用于域名系统（DNS）的其他可选资源记录。这些可选资源记录用于标识符定位器网络协议（ILNP）。本文件是IRTF路由研究组的产品。
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 document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表互联网研究任务组（IRTF）路由研究组一名或多名成员的个人意见。IRSG批准发布的文件不适用于任何级别的互联网标准；见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/rfc6742.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6742.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
不得修改本文件，也不得创建其衍生作品，除非将其格式化为RFC出版或将其翻译为英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Document Roadmap ...........................................4
1.2. Terminology ................................................5
2. New Resource Records ............................................5
2.1. The NID Resource Record ....................................5
2.2. The L32 Resource Record ....................................7
2.3. The L64 Resource Record ...................................10
2.4. The LP Resource Record ....................................12
3. Deployment Example .............................................15
3.1. Use of ILNP Records .......................................15
3.2. Additional Section Processing .............................16
4. Security Considerations ........................................17
5. IANA Considerations ............................................17
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................18
7. Acknowledgements ...............................................20
1. Introduction ....................................................2
1.1. Document Roadmap ...........................................4
1.2. Terminology ................................................5
2. New Resource Records ............................................5
2.1. The NID Resource Record ....................................5
2.2. The L32 Resource Record ....................................7
2.3. The L64 Resource Record ...................................10
2.4. The LP Resource Record ....................................12
3. Deployment Example .............................................15
3.1. Use of ILNP Records .......................................15
3.2. Additional Section Processing .............................16
4. Security Considerations ........................................17
5. IANA Considerations ............................................17
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................18
7. Acknowledgements ...............................................20
This document is part of the ILNP document set, which has had extensive review within the IRTF Routing RG. ILNP is one of the recommendations made by the RG Chairs. Separately, various refereed research papers on ILNP have also been published during this decade. So, the ideas contained herein have had much broader review than the IRTF Routing RG. The views in this document were considered controversial by the Routing RG, but the RG reached a consensus that the document still should be published. The Routing RG has had remarkably little consensus on anything, so virtually all Routing RG outputs are considered controversial.
本文件是ILNP文件集的一部分，已在IRTF路由RG内进行了广泛审查。ILNP是RG主席提出的建议之一。另外，在这十年中还发表了各种关于ILNP的参考研究论文。因此，本文所包含的思想比IRTF路由RG有更广泛的审查。本文件中的观点被路由RG认为是有争议的，但RG达成共识，即该文件仍应发布。路由RG在任何事情上几乎没有共识，因此几乎所有路由RG输出都被认为是有争议的。
At present, the Internet research and development community is exploring various approaches to evolving the Internet Architecture to solve a variety of issues including, but not limited to, scalability of inter-domain routing [RFC4984]. A wide range of other issues (e.g., site multihoming, node multihoming, site/subnet mobility, node mobility) are also active concerns at present. Several different classes of evolution are being considered by the Internet research and development community. One class is often called "Map and Encapsulate", where traffic would be mapped and then tunnelled through the inter-domain core of the Internet. Another class being considered is sometimes known as "Identifier/Locator Split". This document relates to a proposal that is in the latter class of evolutionary approaches.
目前，互联网研发界正在探索各种方法来改进互联网体系结构，以解决各种问题，包括但不限于域间路由的可扩展性[RFC4984]。目前，广泛的其他问题（例如，站点多主、节点多主、站点/子网移动性、节点移动性）也是人们关注的热点。互联网研发界正在考虑几种不同的进化类型。一个类通常被称为“映射和封装”，在这个类中，流量将被映射，然后通过互联网的域间核心进行隧道传输。考虑的另一类有时称为“标识符/定位器拆分”。本文件涉及后一类进化方法中的建议。
The Identifier-Locator Network Protocol (ILNP) was developed to explore a possible evolutionary direction for the Internet Architecture. A description of the ILNP architecture is available in a separate document [RFC6740]. Implementation and engineering details are largely isolated into a second document [RFC6741].
开发标识符定位器网络协议（ILNP）是为了探索互联网体系结构的可能发展方向。ILNP体系结构的描述在单独的文档[RFC6740]中提供。实施和工程细节在很大程度上独立于第二个文档[RFC6741]。
The Domain Name System (DNS) is the standard way that Internet nodes locate information about addresses, mail exchangers, and other data relating to remote Internet nodes [RFC1034] [RFC1035].
域名系统（DNS）是Internet节点定位有关地址、邮件交换器和其他远程Internet节点相关数据的信息的标准方式[RFC1034][RFC1035]。
More recently, the IETF has defined standards-track security extensions to the DNS [RFC4033]. These security extensions can be used to authenticate signed DNS data records and can be used to store signed public keys in the DNS. Further, the IETF has defined a standards-track approach to enable secure dynamic update of DNS records over the network [RFC3007].
最近，IETF定义了DNS的标准跟踪安全扩展[RFC4033]。这些安全扩展可用于验证签名的DNS数据记录，并可用于在DNS中存储签名的公钥。此外，IETF还定义了一种标准跟踪方法，以通过网络实现DNS记录的安全动态更新[RFC3007]。
This document defines several new optional data resource records. This note specifies the syntax and other items required for independent implementations of these DNS resource records. The reader is assumed to be familiar with the basics of DNS, including familiarity with [RFC1034] [RFC1035].
本文档定义了几个新的可选数据资源记录。本说明指定了独立实现这些DNS资源记录所需的语法和其他项。假定读者熟悉DNS的基础知识，包括熟悉[RFC1034][RFC1035]。
The concept of using DNS for rendezvous with mobile nodes or mobile networks has been proposed earlier, more than once, independently, by several other researchers; for example, please see [SB00], [SBK01], and [PHG02].
使用DNS与移动节点或移动网络会合的概念已经被其他几位研究人员提前提出，并且不止一次独立提出；例如，请参见[SB00]、[SBK01]和[PHG02]。
This document describes defines additional DNS resource records that support ILNP.
本文档描述定义支持ILNP的其他DNS资源记录。
The ILNP architecture can have more than one engineering instantiation. For example, one can imagine a "clean-slate" engineering design based on the ILNP architecture. In separate documents, we describe two specific engineering instances of ILNP. The term "ILNPv6" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv6. The term "ILNPv4" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv4.
ILNP体系结构可以有多个工程实例。例如，可以想象基于ILNP体系结构的“干净板岩”工程设计。在单独的文档中，我们描述了ILNP的两个具体工程实例。术语“ILNPv6”正是指基于IPv6并向后兼容IPv6的ILNP实例。术语“ILNPv4”正是指基于IPv4并向后兼容IPv4的ILNP实例。
Many engineering aspects common to both ILNPv4 and ILNPv6 are described in [RFC6741]. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document.
[RFC6741]中描述了ILNPv4和ILNPv6共同的许多工程方面。ILNPv6或ILNPv4的完整工程规范超出了本文件的范围。
Readers are referred to other related ILNP documents for details not described here:
读者可参考其他相关ILNP文件，了解此处未描述的详细信息：
a) [RFC6740] is the main architectural description of ILNP, including the concept of operations.
a) [RFC6740]是ILNP的主要架构描述，包括操作概念。
b) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
b) [RFC6741]描述了ILNPv4和ILNPv6通用的工程和实施注意事项。
c) [RFC6743] defines a new ICMPv6 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
c) [RFC6743]定义一条新的ICMPv6定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
d) [RFC6744] defines a new IPv6 Nonce Destination Option used by ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by inclusion within the initial packets of an ILNP session) that the node is operating in the ILNP mode and (2) to prevent off-path attacks against ILNP ICMP messages. This Nonce is used, for example, with all ILNP ICMPv6 Locator Update messages that are exchanged among ILNP correspondent nodes.
d) [RFC6744]定义了一个新的IPv6 Nonce Destination选项，ILNPv6节点使用该选项（1）向ILNP对应节点（通过包含在ILNP会话的初始数据包中）指示该节点正在ILNP模式下运行，（2）防止针对ILNP ICMP消息的非路径攻击。例如，此Nonce用于在ILNP对应节点之间交换的所有ILNP ICMPv6定位器更新消息。
e) [RFC6745] defines a new ICMPv4 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
e) [RFC6745]定义一条新的ICMPv4定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
f) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to carry a security nonce to prevent off-path attacks against ILNP ICMP messages and also defines a new IPv4 Identifier Option used by ILNPv4 nodes.
f) [RFC6746]定义了一个新的IPv4 Nonce选项，ILNPv4节点使用该选项携带一个安全Nonce，以防止针对ILNP ICMP消息的非路径攻击，还定义了一个新的IPv4标识符选项，ILNPv4节点使用该选项。
g) [RFC6747] describes extensions to Address Resolution Protocol (ARP) for use with ILNPv4.
g) [RFC6747]描述了用于ILNPv4的地址解析协议（ARP）扩展。
h) [RFC6748] describes optional engineering and deployment functions for ILNP. These are not required for the operation or use of ILNP and are provided as additional options.
h) [RFC6748]描述了ILNP的可选工程和部署功能。ILNP的操作或使用不需要这些，而是作为附加选项提供的。
In this document, the term "ILNP-aware" applied to a DNS component (either authoritative server or cache) is used to indicate that the component attempts to include other ILNP RRTypes to the Additional section of a DNS response to increase performance and reduce the number of follow-up queries for other ILNP RRTypes. These other RRsets MAY be added to the Additional section if space permits and only when the QTYPE equals NID, L64, L32, or LP. There is no method for a server to signal that it is ILNP-aware.
在本文档中，应用于DNS组件（权威服务器或缓存）的术语“ILNP感知”用于表示该组件试图将其他ILNP RRTYPE包括到DNS响应的附加部分，以提高性能并减少其他ILNP RRTYPE的后续查询数。如果空间允许，并且仅当QTYPE等于NID、L64、L32或LP时，可以将这些其他RRSET添加到附加部分。没有任何方法可以让服务器发出ILNP感知的信号。
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]中所述进行解释。
This document specifies several new and closely related DNS data resource records (RRs). These new RR types have the mnemonics "NID", "L32", "L64", and "LP". These RR types are associated with a Fully Qualified Domain Name (FQDN) that is hereafter called the "owner name". These are part of work on the Identifier-Locator Network Protocol (ILNP) [RFC6740].
本文档指定了几个新的和密切相关的DNS数据资源记录（RRs）。这些新的RR类型有助记符“NID”、“L32”、“L64”和“LP”。这些RR类型与完全限定域名（FQDN）关联，该域名在下文中称为“所有者名称”。这些是标识符定位器网络协议（ILNP）[RFC6740]工作的一部分。
For clarity, throughout this section of this document, the "RDATA" subsections specify the on-the-wire format for these records, while the "Presentation Format" subsections specify the human-readable format used in a DNS configuration file (i.e., "master file" as defined by RFC 1035, Section 5.1).
为清楚起见，在本文件的本节中，“RDATA”小节指定了这些记录的在线格式，而“演示格式”小节指定了DNS配置文件中使用的人类可读格式（即RFC 1035第5.1节定义的“主文件”）。
The Node Identifier (NID) DNS resource record (RR) is used hold values for Node Identifiers that will be used for ILNP-capable nodes.
节点标识符（NID）DNS资源记录（RR）用于保存将用于支持ILNP的节点的节点标识符的值。
NID records are present only for ILNP-capable nodes. This restriction is important; ILNP-capable nodes use the presence of NID records in the DNS to learn that a correspondent node is also ILNP-capable. While erroneous NID records in the DNS for a node that is not ILNP-capable would not prevent communication, such erroneous DNS records could increase the delay at the start of an IP session.
NID记录仅适用于支持ILNP的节点。这一限制很重要；支持ILNP的节点使用DNS中NID记录的存在来了解对应节点也支持ILNP。虽然DNS中不支持ILNP的节点的错误NID记录不会阻止通信，但此类错误DNS记录可能会增加IP会话开始时的延迟。
A given owner name may have zero or more NID records at a given time. In normal operation, nodes that support the Identifier-Locator Network Protocol (ILNP) will have at least one valid NID record.
给定的所有者名称在给定时间可能有零个或多个NID记录。在正常操作中，支持标识符定位器网络协议（ILNP）的节点将至少有一条有效的NID记录。
The type value for the NID RR type is 104.
NID RR类型的类型值为104。
The NID RR is class independent.
NID RR是独立于类的。
The NID RR has no special Time to Live (TTL) requirements.
NID RR没有特殊的生存时间（TTL）要求。
The RDATA for an NID RR consists of:
NID RR的RDATA包括：
- a 16-bit Preference field - a 64-bit NodeID field
- 16位首选项字段-64位NodeID字段
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| NodeID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| NodeID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <Preference> field contains a 16-bit unsigned integer in network byte order that indicates the owner name's relative preference for this NID record among other NID records associated with this owner name. Lower Preference values are preferred over higher Preference values.
<Preference>字段包含一个网络字节顺序的16位无符号整数，表示所有者名称在与此所有者名称关联的其他NID记录中对此NID记录的相对首选项。较低的首选项值优先于较高的首选项值。
The NodeID field is an unsigned 64-bit value in network byte order. It complies with the syntactic rules of IPv6 interface identifiers [RFC4291], Section 2.5.1, but has slightly different semantics. Unlike IPv6 interface identifiers, which are bound to a specific *interface* of a specific node, NodeID values are bound to a specific *node*, and they MAY be used with *any interface* of that node.
NodeID字段是网络字节顺序的无符号64位值。它符合IPv6接口标识符[RFC4291]第2.5.1节的语法规则，但语义略有不同。与绑定到特定节点的特定*接口*的IPv6接口标识符不同，NodeID值绑定到特定*节点*，并且可以与该节点的*任何接口*一起使用。
The presentation of the format of the RDATA portion is as follows:
RDATA部分的格式表示如下：
- The Preference field MUST be represented as a 16-bit unsigned decimal integer.
- 首选项字段必须表示为16位无符号十进制整数。
- The NodeID field MUST be represented using the same syntax (i.e., groups of 4 hexadecimal digits, with each group separated by a colon) that is already used for DNS AAAA records (and also used for IPv6 interface IDs).
- NodeID字段必须使用已经用于DNS AAAA记录（也用于IPv6接口ID）的相同语法（即，由4个十六进制数字组成的组，每个组由冒号分隔）表示。
- The NodeID value MUST NOT be in the 'compressed' format (e.g., using "::") that is defined in RFC 4291, Section 2.2 (2). This restriction exists to avoid confusion with 128-bit IPv6 addresses, because the NID is a 64-bit field.
- NodeID值不得采用RFC 4291第2.2（2）节中定义的“压缩”格式（例如，使用“：”）。存在此限制是为了避免与128位IPv6地址混淆，因为NID是64位字段。
An NID record has the following logical components:
NID记录具有以下逻辑组件：
<owner-name> IN NID <Preference> <NodeID>
<owner-name> IN NID <Preference> <NodeID>
In the above, <owner-name> is the owner name string, <Preference> is an unsigned 16-bit value, and <NodeID> is an unsigned 64-bit value.
在上面的示例中，<owner name>是所有者名称字符串，<Preference>是无符号16位值，<NodeID>是无符号64位值。
host1.example.com. IN NID 10 0014:4fff:ff20:ee64
host1.example.com. IN NID 20 0015:5fff:ff21:ee65
host2.example.com. IN NID 10 0016:6fff:ff22:ee66
host1.example.com. IN NID 10 0014:4fff:ff20:ee64
host1.example.com. IN NID 20 0015:5fff:ff21:ee65
host2.example.com. IN NID 10 0016:6fff:ff22:ee66
As NodeID values use the same syntax as IPv6 interface identifiers, when displayed for human readership, the NodeID values are presented in the same hexadecimal format as IPv6 interface identifiers. This is shown in the example above.
由于NodeID值使用与IPv6接口标识符相同的语法，因此当为人类读者显示时，NodeID值以与IPv6接口标识符相同的十六进制格式显示。这在上面的示例中显示。
To improve performance, ILNP-aware DNS servers and DNS resolvers MAY attempt to return all L32, L64, and LP records for the same owner name of the NID RRset in the Additional section of the response, if space permits.
为了提高性能，支持ILNP的DNS服务器和DNS解析程序可以尝试在响应的附加部分中返回NID RRset的相同所有者名称的所有L32、L64和LP记录（如果空间允许）。
An L32 DNS RR is used to hold 32-bit Locator values for ILNPv4-capable nodes.
L32 DNS RR用于保存支持ILNPv4的节点的32位定位器值。
L32 records are present only for ILNPv4-capable nodes. This restriction is important; ILNP-capable nodes use the presence of L32 records in the DNS to learn that a correspondent node is also ILNPv4-capable. While erroneous L32 records in the DNS for a node that is not ILNP-capable would not prevent communication, such erroneous DNS records could increase the delay at the start of an IP session.
L32记录仅适用于支持ILNPv4的节点。这一限制很重要；支持ILNP的节点使用DNS中L32记录的存在来了解对应节点也支持ILNPv4。虽然DNS中不支持ILNP的节点的错误L32记录不会阻止通信，但此类错误DNS记录可能会增加IP会话开始时的延迟。
A given owner name might have zero or more L32 values at a given time. An ILNPv4-capable host SHOULD have at least 1 Locator (i.e., L32 or LP) DNS resource record while it is connected to the Internet. An ILNPv4-capable multihomed host normally will have multiple Locator values while multihomed. An IP host that is NOT ILNPv4-capable MUST NOT have an L32 or LP record in its DNS entries. A node that is not currently connected to the Internet might not have any L32 values in the DNS associated with its owner name.
给定的所有者名称在给定时间可能有零个或多个L32值。支持ILNPv4的主机在连接到Internet时应至少具有1个定位程序（即L32或LP）DNS资源记录。支持ILNPv4的多宿主主机通常在多宿主时具有多个定位器值。不支持ILNPv4的IP主机的DNS条目中不得有L32或LP记录。当前未连接到Internet的节点在DNS中可能没有与其所有者名称关联的任何L32值。
A DNS owner name that is naming a subnetwork, rather than naming a host, MAY have an L32 record as a wild-card entry, thereby applying to entries under that DNS owner name. This deployment scenario probably is most common if the named subnetwork is, was, or might become, mobile.
命名子网络而不是命名主机的DNS所有者名称可能将L32记录作为通配符条目，从而应用于该DNS所有者名称下的条目。如果指定的子网是、曾经是或可能成为移动的，则此部署场景可能最常见。
The type value for the L32 RR type is 105.
L32 RR类型的类型值为105。
The L32 RR is class independent.
L32 RR与类别无关。
The L32 RR has no special TTL requirements.
L32 RR没有特殊的TTL要求。
The RDATA for an L32 RR consists of:
L32 RR的RDATA包括：
- a 16-bit Preference field - a 32-bit Locator32 field
- 16位首选项字段-32位定位器32字段
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | Locator32 (16 MSBs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator32 (16 LSBs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | Locator32 (16 MSBs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator32 (16 LSBs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MSB = most significant bit LSB = least significant bit
MSB=最高有效位LSB=最低有效位
The <Preference> field is an unsigned 16-bit field in network byte order that indicates the owner name's relative preference for this L32 record among other L32 records associated with this owner name. Lower Preference values are preferred over higher Preference values.
<Preference>字段是一个以网络字节顺序排列的无符号16位字段，表示所有者名称在与此所有者名称关联的其他L32记录中对此L32记录的相对偏好。较低的首选项值优先于较高的首选项值。
The <Locator32> field is an unsigned 32-bit integer in network byte order that is identical on-the-wire to the ADDRESS field of the existing DNS A record.
<Locator32>字段是一个网络字节顺序的无符号32位整数，在线路上与现有DNS A记录的地址字段相同。
The presentation of the format of the RDATA portion is as follows:
RDATA部分的格式表示如下：
- The Preference field MUST be represented as a 16-bit unsigned decimal integer.
- 首选项字段必须表示为16位无符号十进制整数。
- The Locator32 field MUST be represented using the same syntax used for existing DNS A records (i.e., 4 decimal numbers separated by periods without any embedded spaces).
- Locator32字段必须使用与现有DNS A记录相同的语法表示（即，由句点分隔的4个十进制数字，无任何嵌入空格）。
An L32 record has the following logical components:
L32记录具有以下逻辑组件：
<owner-name> IN L32 <Preference> <Locator32>
<owner-name> IN L32 <Preference> <Locator32>
In the above <owner-name> is the owner name string, <Preference> is an unsigned 16-bit value, and <Locator32> is an unsigned 32-bit value.
在上面的示例中，<owner name>是所有者名称字符串，<Preference>是无符号16位值，<Locator32>是无符号32位值。
host1.example.com. IN L32 10 10.1.02.0 host1.example.com. IN L32 20 10.1.04.0 host2.example.com. IN L32 10 10.1.08.0
host1.example.com。在L32 10 10.1.02.0 host1.example.com中。在L32 20 10.1.04.0 host2.example.com中。在L32 10.1.08.0中
As L32 values have the same syntax and semantics as IPv4 routing prefixes, when displayed for human readership, the values are presented in the same dotted-decimal format as IPv4 addresses. An example of this syntax is shown above.
由于L32值与IPv4路由前缀具有相同的语法和语义，因此当为人类读者显示时，这些值以与IPv4地址相同的点十进制格式显示。上面显示了此语法的一个示例。
In the example above, the owner name is from an FQDN for an individual host. host1.example.com has two L32 values, so host1.example.com is multihomed.
在上面的示例中，所有者名称来自单个主机的FQDN。host1.example.com有两个L32值，因此host1.example.com是多址的。
Another example is when the owner name is that learned from an LP record (see below for details of LP records).
另一个例子是，所有者名称是从LP记录中学习到的名称（有关LP记录的详细信息，请参见下文）。
l32-subnet1.example.com. IN L32 10 10.1.02.0 l32-subnet2.example.com. IN L32 20 10.1.04.0 l32-subnet3.example.com. IN L32 30 10.1.08.0
l32-subnet1.example.com。在L32 10 10.1.02.0 L32-subnet2.example.com中。在L32 20 10.1.04.0 L32-subnet3.example.com中。在L32 30 10.1.08.0中
In this example above, the owner name is for a subnetwork rather than an individual node.
在上面的示例中，所有者名称用于子网络，而不是单个节点。
To improve performance, ILNP-aware DNS servers and DNS resolvers MAY attempt to return all NID, L64, and LP records for the same owner name of the L32 RRset in the Additional section of the response, if space permits.
为了提高性能，支持ILNP的DNS服务器和DNS解析程序可以尝试在响应的附加部分中返回L32 RRset的相同所有者名称的所有NID、L64和LP记录（如果空间允许）。
The L64 resource record (RR) is used to hold unsigned 64-bit Locator values for ILNPv6-capable nodes.
L64资源记录（RR）用于保存支持ILNPv6的节点的无符号64位定位器值。
L64 records are present only for ILNPv6-capable nodes. This restriction is important; ILNP-capable nodes use the presence of L64 records in the DNS to learn that a correspondent node is also ILNPv6-capable. While erroneous L64 records in the DNS for a node that is not ILNP-capable would not prevent communication, such erroneous DNS records could increase the delay at the start of an IP session.
L64记录仅适用于支持ILNPv6的节点。这一限制很重要；支持ILNP的节点使用DNS中L64记录的存在来了解对应节点也支持ILNPv6。虽然DNS中不支持ILNP的节点的错误L64记录不会阻止通信，但此类错误DNS记录可能会增加IP会话开始时的延迟。
A given owner name might have zero or more L64 values at a given time. An ILNPv6-capable host SHOULD have at least 1 Locator (i.e., L64 or LP) DNS resource record while it is connected to the Internet. An ILNPv6-capable multihomed host normally will have multiple Locator values while multihomed. An IP host that is NOT ILNPv6-capable MUST NOT have an L64 or LP record in its DNS entries. A node that is not currently connected to the Internet might not have any L64 values in the DNS associated with its owner name.
给定的所有者名称在给定时间可能有零个或多个L64值。支持ILNPv6的主机在连接到Internet时应至少具有1个定位程序（即L64或LP）DNS资源记录。支持ILNPv6的多宿主主机通常在多宿主时具有多个定位器值。不支持ILNPv6的IP主机的DNS条目中不得有L64或LP记录。当前未连接到Internet的节点可能在与其所有者名称关联的DNS中没有任何L64值。
A DNS owner name that is naming a subnetwork, rather than naming a host, MAY have an L64 record as a wild-card entry, thereby applying to entries under that DNS owner name. This deployment scenario probably is most common if the named subnetwork is, was, or might become, mobile.
命名子网络而不是命名主机的DNS所有者名称可能具有L64记录作为通配符条目，从而应用于该DNS所有者名称下的条目。如果指定的子网是、曾经是或可能成为移动的，则此部署场景可能最常见。
The type value for the L64 RR type is 106.
L64 RR类型的类型值为106。
The L64 RR is class independent.
L64 RR与类无关。
The L64 RR has no special TTL requirements.
L64 RR没有特殊的TTL要求。
The RDATA for an L64 RR consists of:
L64 RR的RDATA包括：
- a 16-bit Preference field - a 64-bit Locator64 field
- 16位首选项字段-64位定位器64位字段
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Locator64 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Locator64 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <Preference> field is an unsigned 16-bit integer in network byte order that indicates the owner name's relative preference for this L64 record among other L64 records associated with this owner name. Lower Preference values are preferred over higher Preference values.
<Preference>字段是一个网络字节顺序的无符号16位整数，表示所有者名称在与此所有者名称关联的其他L64记录中对此L64记录的相对首选项。较低的首选项值优先于较高的首选项值。
The <Locator64> field is an unsigned 64-bit integer in network byte order that has the same syntax and semantics as a 64-bit IPv6 routing prefix.
<Locator64>字段是网络字节顺序的无符号64位整数，其语法和语义与64位IPv6路由前缀相同。
The presentation of the format of the RDATA portion is as follows:
RDATA部分的格式表示如下：
- The Preference field MUST be represented as a 16-bit unsigned decimal integer.
- 首选项字段必须表示为16位无符号十进制整数。
- The Locator64 field MUST be represented using the same syntax used for AAAA records (i.e., groups of 4 hexadecimal digits separated by colons). However, the 'compressed' display format (e.g., using "::") that is specified in RFC 4291, Section 2.2 (2), MUST NOT be used. This is done to avoid confusion with a 128-bit IPv6 address, since the Locator64 is a 64-bit value, while the IPv6 address is a 128-bit value.
- Locator64字段必须使用与AAAA记录相同的语法表示（即，由4个十六进制数字组成的组，用冒号分隔）。但是，不得使用RFC 4291第2.2（2）节中规定的“压缩”显示格式（例如，使用“：”）。这样做是为了避免与128位IPv6地址混淆，因为Locator64是64位值，而IPv6地址是128位值。
An L64 record has the following logical components:
L64记录具有以下逻辑组件：
<owner-name> IN L64 <Preference> <Locator64>
<owner-name> IN L64 <Preference> <Locator64>
In the above, <owner-name> is the owner name string, <Preference> is an unsigned 16-bit value, while <Locator64> is an unsigned 64-bit value.
在上面的示例中，<owner name>是所有者名称字符串，<Preference>是无符号16位值，<Locator64>是无符号64位值。
host1.example.com. IN L64 10 2001:0DB8:1140:1000
host1.example.com. IN L64 20 2001:0DB8:2140:2000
host2.example.com. IN L64 10 2001:0DB8:4140:4000
host1.example.com. IN L64 10 2001:0DB8:1140:1000
host1.example.com. IN L64 20 2001:0DB8:2140:2000
host2.example.com. IN L64 10 2001:0DB8:4140:4000
As L64 values have the same syntax and semantics as IPv6 routing prefixes, when displayed for human readership, the values might conveniently be presented in hexadecimal format, as above.
由于L64值与IPv6路由前缀具有相同的语法和语义，因此当为人类读者显示时，这些值可以方便地以十六进制格式显示，如上所述。
In the example above, the owner name is from an FQDN for an individual host. host1.example.com has two L64 values, so it will be multihomed.
在上面的示例中，所有者名称来自单个主机的FQDN。host1.example.com有两个L64值，因此它将是多宿主的。
Another example is when the owner name is that learned from an LP record (see below for details of LP records).
另一个例子是，所有者名称是从LP记录中学习到的名称（有关LP记录的详细信息，请参见下文）。
l64-subnet1.example.com. IN L64 10 2001:0DB8:1140:1000
l64-subnet2.example.com. IN L64 20 2001:0DB8:2140:2000
l64-subnet3.example.com. IN L64 30 2001:0DB8:4140:4000
l64-subnet1.example.com. IN L64 10 2001:0DB8:1140:1000
l64-subnet2.example.com. IN L64 20 2001:0DB8:2140:2000
l64-subnet3.example.com. IN L64 30 2001:0DB8:4140:4000
Here, the owner name is for a subnetwork rather than an individual node.
在这里，所有者名称用于子网络，而不是单个节点。
To improve performance, ILNP-aware DNS servers and DNS resolvers MAY attempt to return all NID, L32, and LP records for the same owner name of the L64 RRset in the Additional section of the response, if space permits.
为了提高性能，支持ILNP的DNS服务器和DNS解析程序可以尝试在响应的附加部分中返回L64 RRset的相同所有者名称的所有NID、L32和LP记录（如果空间允许）。
The LP DNS resource record (RR) is used to hold the name of a subnetwork for ILNP. The name is an FQDN which can then be used to look up L32 or L64 records. LP is, effectively, a Locator Pointer to L32 and/or L64 records.
LP DNS资源记录（RR）用于保存ILNP的子网名称。该名称是FQDN，可用于查找L32或L64记录。LP实际上是指向L32和/或L64记录的定位器指针。
As described in [RFC6740], the LP RR provides one level of indirection within the DNS in naming a Locator value. This is useful in several deployment scenarios, such as for a multihomed site where the multihoming is handled entirely by the site's border routers (e.g., via Locator rewriting) or in some mobile network deployment scenarios [RFC6748].
如[RFC6740]中所述，LP RR在命名定位器值时在DNS内提供一个间接级别。这在多个部署场景中非常有用，例如多主站点，其中多主完全由站点的边界路由器（例如，通过定位器重写）处理，或者在某些移动网络部署场景中[RFC6748]。
LP records MUST NOT be present for owner name values that are not ILNP-capable nodes. This restriction is important; ILNP-capable nodes use the presence of LP records in the DNS to infer that a correspondent node is also ILNP-capable. While erroneous LP records in the DNS for an owner name would not prevent communication, presence of such erroneous DNS records could increase the delay at the start of an IP session.
对于不支持ILNP的节点，所有者名称值不得存在LP记录。这一限制很重要；支持ILNP的节点使用DNS中LP记录的存在来推断对应节点也支持ILNP。虽然DNS中所有者名称的错误LP记录不会阻止通信，但此类错误DNS记录的存在可能会增加IP会话开始时的延迟。
The type value for the LP RR type is 107.
LP RR类型的类型值为107。
The LP RR is class independent.
LP-RR是独立于类的。
The LP RR has no special TTL requirements.
LP RR没有特殊的TTL要求。
The RDATA for an LP RR consists of:
LP RR的RDATA包括：
- an unsigned 16-bit Preference field - a variable-length FQDN field
- 无符号16位首选项字段-可变长度FQDN字段
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ FQDN /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ FQDN /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <Preference> field contains an unsigned 16-bit integer in network byte order that indicates the owner name's relative preference for this LP record among other LP records associated with this owner name. Lower Preference values are preferred over higher Preference values.
<Preference>字段包含一个网络字节顺序的无符号16位整数，表示所有者名称在与此所有者名称关联的其他LP记录中对此LP记录的相对首选项。较低的首选项值优先于较高的首选项值。
The variable-length FQDN field contains the DNS target name that is used to reference L32 and/or L64 records. This field MUST NOT have the same value as the owner name of the LP RR instance.
可变长度FQDN字段包含用于引用L32和/或L64记录的DNS目标名称。此字段的值不得与LP RR实例的所有者名称相同。
A sender MUST NOT use DNS name compression on the FQDN field when transmitting an LP RR.
在传输LP RR时，发送方不得在FQDN字段上使用DNS名称压缩。
The presentation of the format of the RDATA portion is as follows:
RDATA部分的格式表示如下：
- The Preference field MUST be represented as a 16-bit unsigned decimal integer.
- 首选项字段必须表示为16位无符号十进制整数。
- The FQDN field MUST be represented as a domain name.
- FQDN字段必须表示为域名。
An LP record has the following logical components:
LP记录具有以下逻辑组件：
<owner-name> IN LP <Preference> <FQDN>
<owner-name> IN LP <Preference> <FQDN>
In the above, <owner-name> is the owner name string, <Preference> is an unsigned 16-bit value, while <FQDN> is the domain name which should be resolved further.
在上面的例子中，<owner name>是所有者名称字符串，<Preference>是一个无符号的16位值，<FQDN>是应该进一步解析的域名。
host1.example.com. IN LP 10 l64-subnet1.example.com. host1.example.com. IN LP 10 l64-subnet2.example.com. host1.example.com. IN LP 20 l32-subnet1.example.com.
host1.example.com。在LP 10 l64-subnet1.example.com中。host1.example.com。在LP 10 l64-subnet2.example.com中。host1.example.com。在LP 20 l32-subnet1.example.com中。
In the example above, host1.example.com is multihomed on three subnets. Resolving the FQDNs return in the LP records would allow the actual subnet prefixes to be resolved, e.g., as in the examples for the L32 and L64 RR descriptions, above. This level of indirection allows the same L32 and/or L64 records to be used by many hosts in the same subnetwork, easing management of the ILNP network and potentially reducing the number of DNS Update transactions, especially when that network is mobile [RAB09] or multihomed [ABH09a].
在上面的示例中，host1.example.com在三个子网上多址。解析LP记录中的FQDNs返回将允许解析实际子网前缀，例如，如上文L32和L64 RR描述的示例所示。这种间接级别允许相同的L32和/或L64记录被同一子网中的许多主机使用，从而简化了ILNP网络的管理，并可能减少DNS更新事务的数量，特别是当该网络是移动的[RAB09]或多址的[ABH09a]时。
To improve performance, ILNP-aware DNS servers and DNS resolvers MAY attempt to return all L32 and L64 records for the same owner name of the LP RRset in the Additional section of the response, if space permits.
为了提高性能，支持ILNP的DNS服务器和DNS解析程序可以尝试在响应的附加部分中返回LP RRset的相同所有者名称的所有L32和L64记录（如果空间允许）。
Given a domain name, one can use the Domain Name System (DNS) to discover the set of NID records, the set of L32 records, the set of L64 records, and the set of LP records that are associated with that DNS owner name.
给定域名，可以使用域名系统（DNS）查找与该DNS所有者名称关联的NID记录集、L32记录集、L64记录集和LP记录集。
For example:
例如：
host1.example.com. IN NID 10 0014:4fff:ff20:ee64
host1.example.com. IN L64 10 2001:0DB8:1140:1000
host1.example.com. IN NID 10 0014:4fff:ff20:ee64
host1.example.com. IN L64 10 2001:0DB8:1140:1000
would be the minimum requirement for an ILNPv6 node that has owner name host1.example.com and is connected to the Internet at the subnetwork having routing prefix 2001:0DB8:1140:1000.
对于拥有者名称为host1.example.com且在路由前缀为2001:0DB8:1140:1000的子网处连接到Internet的ILNPv6节点，这是最低要求。
If that host were multihomed on two different IPv6 subnets:
如果该主机位于两个不同的IPv6子网上：
host1.example.com. IN NID 10 0014:4fff:ff20:ee64
host1.example.com. IN L64 10 2001:0DB8:1140:1000
host1.example.com. IN L64 20 2001:0DB8:2140:2000
host1.example.com. IN NID 10 0014:4fff:ff20:ee64
host1.example.com. IN L64 10 2001:0DB8:1140:1000
host1.example.com. IN L64 20 2001:0DB8:2140:2000
would indicate the Identifier and two subnets that host1.example.com is attached to, along with the relative preference that a client would use in selecting the Locator value for use in initiating communication.
将指示host1.example.com连接到的标识符和两个子网，以及客户端在选择用于启动通信的定位器值时使用的相对首选项。
If host1.example.com were part of a mobile network, a DNS query might return:
如果host1.example.com是移动网络的一部分，DNS查询可能会返回：
host1.example.com. IN NID 10 0014:4fff:ff20:ee64 host1.example.com. IN LP 10 mobile-net1.example.com.
host1.example.com。在NID 10 0014:4fff:ff20:ee64 host1.example.com中。在LP 10 mobile-net1.example.com中。
and then a DNS query to find the current Locator value(s) for the node named by the LP record:
然后进行DNS查询，以查找由LP记录命名的节点的当前定位器值：
mobile-net1.example.com. IN L64 2001:0DB8:8140:8000
mobile-net1.example.com. IN L64 2001:0DB8:8140:8000
As these DNS records are only used with the Identifier-Locator Network Protocol (ILNP), these records MUST NOT be present for a node that does not support ILNP. This lookup process is considered to be in the "forward" direction.
由于这些DNS记录仅与标识符定位器网络协议（ILNP）一起使用，因此不支持ILNP的节点不得存在这些记录。此查找过程被认为是“正向”的。
The Preference fields associated with the NID, L32, L64, and LP records are used to indicate the owner name's preference for others to use one particular NID, L32, L64, or LP record, rather than use
与NID、L32、L64和LP记录关联的首选项字段用于指示所有者名称对其他人使用特定NID、L32、L64或LP记录的首选项，而不是使用
another NID, L32, L64, or LP record also associated with that owner name. Lower Preference field values are preferred over higher Preference field values.
另一个NID、L32、L64或LP记录也与该所有者名称关联。较低的首选字段值优先于较高的首选字段值。
It is possible that a DNS stub resolver querying for one of these record types will not receive all NID, L32, L64, and LP RR's in a single response. Credible anecdotal reports indicate at least one DNS recursive cache implementation actively drops all Additional Data records that were not expected by that DNS recursive cache. So even if the authoritative DNS server includes all the relevant records in the Additional Data section of the DNS response, the querying DNS stub resolver might not receive all of those Additional Data records. DNS resolvers also might purge some ILNP RRsets before others, for example, if NID RRsets have a longer DNS TTL value than Locator-related (e.g., LP, L32, L64) RRsets. So a DNS stub resolver sending queries to a DNS resolver cannot be certain if they have obtained all available RRtypes for a given owner name. Therefore, the DNS stub resolver SHOULD send follow-up DNS queries for RRTYPE values that were missing and are desired, to ensure that the DNS stub resolver receives all the necessary information.
查询这些记录类型之一的DNS存根解析器可能不会在单个响应中接收所有NID、L32、L64和LP RR。可靠的轶事报告表明，至少有一个DNS递归缓存实现会主动删除该DNS递归缓存未预期的所有其他数据记录。因此，即使权威DNS服务器包括DNS响应的附加数据部分中的所有相关记录，查询DNS存根解析器也可能不会接收所有这些附加数据记录。DNS解析程序还可能先清除某些ILNP RRSET，例如，如果NID RRSET的DNS TTL值比与定位器相关的（例如LP、L32、L64）RRSET长。因此，向DNS解析程序发送查询的DNS存根解析程序无法确定是否已获得给定所有者名称的所有可用RRTYPE。因此，DNS存根解析程序应发送后续DNS查询，以查找缺失的和需要的RRTYPE值，以确保DNS存根解析程序接收所有必要的信息。
Note nodes likely either to be mobile or to be multihomed normally will have very low DNS TTL values for L32 and L64 records, as those values might change frequently. However, the DNS TTL values for NID and LP records normally will be higher, as those values are not normally impacted by node location changes. Previous trace-driven DNS simulations from MIT [JSBM02] and more recent experimental validation of operational DNS from U. of St Andrews [BA11] both indicate deployment and use of very short DNS TTL values within 'stub' or 'leaf' DNS domains is not problematic.
注意：对于L32和L64记录，可能是移动的或通常是多址的节点将具有非常低的DNS TTL值，因为这些值可能会频繁更改。但是，NID和LP记录的DNS TTL值通常较高，因为这些值通常不受节点位置更改的影响。先前来自麻省理工学院[JSBM02]的跟踪驱动DNS模拟和最近来自圣安德鲁斯大学[BA11]的运行DNS实验验证都表明在“存根”或“叶”DNS域中部署和使用非常短的DNS TTL值没有问题。
An ILNP node MAY use any NID value associated with its DNS owner name with any or all Locator (L32 or L64) values also associated with its DNS owner name.
ILNP节点可以使用与其DNS所有者名称相关联的任何NID值以及与其DNS所有者名称相关联的任何或所有定位器（L32或L64）值。
Existing DNS servers that do not explicitly support the new DNS RRs defined in this specification are expected to follow existing standards for handling unknown DNS RRs [RFC3597].
不明确支持本规范中定义的新DNS RRs的现有DNS服务器应遵循处理未知DNS RRs的现有标准[RFC3597]。
For all the records above, Additional Section Processing MAY be used. This is intended to improve performance for both the DNS client and the DNS server. For example, a node sending DNS query for an NID owner name, such as host1.example.com, would benefit from receiving all ILNP DNS records related to that owner name being returned, as it is quite likely that the client will need that information to initiate an ILNP session.
对于上述所有记录，可使用额外的区段处理。这旨在提高DNS客户端和DNS服务器的性能。例如，发送NID所有者名称的DNS查询（如host1.example.com）的节点将受益于接收与该所有者名称相关的所有ILNP DNS记录，因为客户端很可能需要该信息来启动ILNP会话。
However, this is not always the case: a DNS query for L64 for a particular owner name might be made because the DNS TTL for a previously resolved L64 RR has expired, while the NID RR for that same owner name has a DNS TTL that has not expired.
但是，情况并非总是如此：可能会对特定所有者名称的L64进行DNS查询，因为先前解析的L64 RR的DNS TTL已过期，而该所有者名称的NID RR的DNS TTL尚未过期。
These new DNS resource record types do not create any new vulnerabilities in the Domain Name System.
这些新的DNS资源记录类型不会在域名系统中创建任何新的漏洞。
Existing mechanisms for DNS Security can be used unchanged with these record types [RFC4033] [RFC3007]. As of this writing, the DNS Security mechanisms are believed to be widely implemented in currently available DNS servers and DNS clients. Deployment of DNS Security appears to be growing rapidly.
现有的DNS安全机制可以在不改变这些记录类型的情况下使用[RFC4033][RFC3007]。在撰写本文时，人们认为DNS安全机制已广泛应用于当前可用的DNS服务器和DNS客户端中。DNS安全的部署似乎正在快速增长。
In situations where authentication of DNS data is a concern, the DNS Security extensions SHOULD be used [RFC4033].
在涉及DNS数据身份验证的情况下，应使用DNS安全扩展[RFC4033]。
If these DNS records are updated dynamically over the network, then the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be used to secure such transactions.
如果这些DNS记录通过网络动态更新，则应使用安全动态DNS更新[RFC3007]机制来保护此类交易。
IANA has allocated each of the following DNS resource records (described above in Section 2) a Data RRTYPE value according to the procedures of Sections 3.1 and 3.1.1 of [RFC6195].
IANA已根据[RFC6195]第3.1节和第3.1.1节的程序为以下每个DNS资源记录（如上文第2节所述）分配了数据RRTYPE值。
Type Value
---- -----
NID 104
L32 105
L64 106
LP 107
Type Value
---- -----
NID 104
L32 105
L64 106
LP 107
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[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月。
[RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011.
[RFC6195]Eastlake 3rd，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 61952011年3月。
[RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, November 2012.
[RFC6740]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）体系结构描述”，RFC 67402012年11月。
[RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations", RFC 6741, November 2012.
[RFC6741]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）工程和实施注意事项”，RFC 67412012年11月。
[ABH09a] Atkinson, R., Bhatti, S. and S. Hailes, "Site-Controlled Secure Multi-Homing and Traffic Engineering For IP", Proceedings of IEEE Military Communications Conference, IEEE, Boston, MA, USA, October 2009.
[ABH09a]Atkinson，R.，Bhatti，S.和S.Hailes，“IP的现场控制安全多址和流量工程”，IEEE军事通信会议记录，IEEE，波士顿，马萨诸塞州，美国，2009年10月。
[BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching",
Proceedings of IEEE Global Internet Symposium (GI2011),
Shanghai, P.R. China. 15 April 2011.
<http://dx.doi.org/10.1109/INFCOMW.2011.5928919>
[BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching",
Proceedings of IEEE Global Internet Symposium (GI2011),
Shanghai, P.R. China. 15 April 2011.
<http://dx.doi.org/10.1109/INFCOMW.2011.5928919>
[JSBM02] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
performance and the effectiveness of caching", IEEE/ACM
Trans. Netw. 10(5) (October 2002), pp 589-603.
<http://dx.doi.org/10.1109/TNET.2002.803905>
[JSBM02] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
performance and the effectiveness of caching", IEEE/ACM
Trans. Netw. 10(5) (October 2002), pp 589-603.
<http://dx.doi.org/10.1109/TNET.2002.803905>
[PHG02] Pappas, A., Hailes, S. and R. Giaffreda, "Mobile Host
Location Tracking through DNS", IEEE London
Communications Symposium, London, England, UK, September
2002.
<http://www.ee.ucl.ac.uk/lcs/previous/LCS2002/LCS072.pdf>
[PHG02] Pappas, A., Hailes, S. and R. Giaffreda, "Mobile Host
Location Tracking through DNS", IEEE London
Communications Symposium, London, England, UK, September
2002.
<http://www.ee.ucl.ac.uk/lcs/previous/LCS2002/LCS072.pdf>
[RAB09] Rehunathan, D., Atkinson, R. and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Boston, MA, USA, October 2009.
[RAB09]Rehunahan，D.，Atkinson，R.和S.Bhatti，“通过安全命名实现移动网络”，IEEE军事通信会议记录（MILCOM），IEEE，波士顿，马萨诸塞州，美国，2009年10月。
[SB00] Snoeren, A. and H. Balakrishnan, "An End-To-End Approach To Host Mobility", Proceedings of 6th Conference on Mobile Computing and Networking (MobiCom), ACM, Boston, MA, USA, August 2000.
[SB00]Snoren，A.和H.Balakrishnan，“主机移动性的端到端方法”，第六届移动计算和网络会议记录（MobiCom），美国马萨诸塞州波士顿ACM，2000年8月。
[SBK01] Snoeren, A., Balakrishnan, H., and M. Frans Kaashoek, "Reconsidering Internet Mobility", Proceedings of 8th Workshop on Hot Topics in Operating Systems (HotOS), IEEE Computer Society, Elmau, Germany, May 2001.
[SBK01]Snoren，A.，Balakrishnan，H.，和M.Frans Kaashoek，“重新考虑互联网移动性”，第八届操作系统热点研讨会论文集，IEEE计算机学会，德国埃尔莫，2001年5月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]Meyer，D.，Ed.，Zhang，L.，Ed.，和K.Fall，Ed.，“IAB路由和寻址研讨会报告”，RFC 4984，2007年9月。
[RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update Message", RFC 6743, November 2012.
[RFC6743]Atkinson，R.和S.Bhatti，“ICMPv6定位器更新消息”，RFC 67432012年11月。
[RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, November 2012.
[RFC6744]Atkinson，R.和S.Bhatti，“IPv6标识符定位器网络协议（ILNPv6）的IPv6临时目的地选项”，RFC 67442012年11月。
[RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)", RFC 6745, November 2012.
[RFC6745]Atkinson，R.和S.Bhatti，“IPv4标识符定位器网络协议（ILNPv4）的ICMP定位器更新消息”，RFC 67452012年11月。
[RFC6746] Atkinson, R. and S.Bhatti, "IPv4 Options for the Identifier-Locator Network Protocol (ILNP)", RFC 6746, November 2012.
[RFC6746]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）的IPv4选项”，RFC 67462012年11月。
[RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol (ARP) Extension for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012.
[RFC6747]Atkinson，R.和S.Bhatti，“IPv4标识符定位器网络协议（ILNPv4）的地址解析协议（ARP）扩展”，RFC 6747，2012年11月。
[RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)", RFC 6748, November 2012.
[RFC6748]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）的可选高级部署场景”，RFC 6748，2012年11月。
Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson, Robin Whittle, and John Wroclawski (in alphabetical order) provided review and feedback on earlier versions of this document. Steve Blake provided an especially thorough review of an early version of the entire ILNP document set, which was extremely helpful. We also wish to thank the anonymous reviewers of the various ILNP papers for their feedback.
Steve Blake、Stephane Bortzmeyer、Mohamed Boucadair、Noel Chiappa、Wes George、Steve Hailes、Joel Halpern、Mark Handley、Volker Hilt、Paul Jakma、Dae Young Kim、Tony Li、Yakov Rehkter、Bruce Simpson、Robin Whittle和John Wroclawski（按字母顺序）对本文件的早期版本进行了审查和反馈。Steve Blake对整个ILNP文档集的早期版本进行了特别彻底的审查，这非常有帮助。我们还要感谢各种ILNP论文的匿名评审员的反馈。
Roy Arends provided expert guidance on technical and procedural aspects of DNS issues, for which the authors are greatly obliged.
Roy Arends就DNS问题的技术和程序方面提供了专家指导，对此作者深表感谢。
Authors' Addresses
作者地址
RJ Atkinson Consultant San Jose, CA 95125 USA
美国加利福尼亚州圣何塞RJ阿特金森咨询公司95125
EMail: rja.lists@gmail.com
EMail: rja.lists@gmail.com
SN Bhatti School of Computer Science University of St Andrews North Haugh, St Andrews Fife, Scotland KY16 9SX, UK
SN BaTHI计算机科学学院圣·安驻斯大学北部豪格，圣安德鲁斯法夫，苏格兰KY16 9SX，英国
EMail: saleem@cs.st-andrews.ac.uk
EMail: saleem@cs.st-andrews.ac.uk
Scott Rose US National Institute for Standards & Technology 100 Bureau Drive Gaithersburg, MD 20899 USA
斯科特·罗斯美国国家标准与技术研究所美国马里兰州盖瑟斯堡路100号局，邮编：20899
EMail: scottr.nist@gmail.com
EMail: scottr.nist@gmail.com