Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6743 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6743 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
IPv6标识符定位器网络协议（ILNPv6）的ICMP定位器更新消息
Abstract
摘要
This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group.
本说明指定了与标识符定位器网络协议（ILNP）一起使用的实验性ICMPv6消息类型。标识符定位网络协议（ILNP）是对IP的一种实验性、进化性增强。此消息用于动态更新现有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/rfc6743.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6743.
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 ....................................................3
1.1. Document Roadmap ...........................................3
1.2. ICMPv6 Locator Update ......................................4
1.3. Terminology ................................................5
2. Syntax ..........................................................5
2.1. Example ICMPv6 Locator Update Message ......................7
3. Transport Protocol Effects ......................................8
4. Implementation Considerations ...................................8
5. Backwards Compatibility .........................................8
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
9. Acknowledgements ...............................................11
1. Introduction ....................................................3
1.1. Document Roadmap ...........................................3
1.2. ICMPv6 Locator Update ......................................4
1.3. Terminology ................................................5
2. Syntax ..........................................................5
2.1. Example ICMPv6 Locator Update Message ......................7
3. Transport Protocol Effects ......................................8
4. Implementation Considerations ...................................8
5. Backwards Compatibility .........................................8
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
9. Acknowledgements ...............................................11
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 are 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]。目前，广泛的其他问题（例如，站点多主、节点多主、站点/子网移动性、节点移动性）也是人们关注的热点。互联网研发界正在考虑几种不同的进化类型。一个类通常被称为“映射和封装”，在这个类中，流量将被映射，然后通过互联网的域间核心进行隧道传输。考虑的另一类有时称为“标识符/定位器拆分”。本文件涉及后一类进化方法中的建议。
This document 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.
本文档定义了一条新的ICMPv6定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
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) [RFC6742] defines additional DNS resource records that support ILNP.
c) [RFC6742]定义支持ILNP的其他DNS资源记录。
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 the 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的操作或使用不需要这些，而是作为附加选项提供的。
As described in [RFC6740] and [RFC6741], an ILNP for IPv6 (ILNPv6) node might need to inform correspondent ILNPv6 nodes of changes to the set of valid Locator values. The new ICMPv6 Locator Update message described in this document enables an ILNP-capable node to update its correspondents about the currently valid set of Locators valid to use in reaching the node sending this message [RFC2460] [RFC4443].
如[RFC6740]和[RFC6741]中所述，IPv6的ILNP（ILNPv6）节点可能需要通知对应的ILNPv6节点有效定位器值集的更改。本文档中描述的新ICMPv6定位器更新消息使支持ILNP的节点能够更新其通信者关于当前有效定位器集的信息，该定位器集可用于到达发送此消息的节点[RFC2460][RFC4443]。
This new ICMPv6 message MUST ONLY be used for ILNPv6 sessions. Authentication is always required, as described in the Security Considerations section later in this note.
此新ICMPv6消息只能用于ILNPv6会话。如本说明后面的安全注意事项部分所述，始终需要身份验证。
Some might consider any and all use of ICMP to be undesirable. In that context, please note that while this specification uses ICMP, on grounds that this is a control message, there is no architectural difference between using ICMP and using some other framing (for example, UDP).
有些人可能认为任何和所有使用ICMP是不可取的。在这种情况下，请注意，虽然本规范使用ICMP，但基于这是一条控制消息，使用ICMP和使用其他帧（例如UDP）之间没有架构上的区别。
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]中所述进行解释。
The ICMPv6 message described in this section has ICMP Type 156 and is used ONLY with a current ILNPv6 session. This message enables an ILNPv6 node to inform ILNPv6 correspondent nodes of changes to the active Locator set for the ILNPv6 node that originates this message. This particular ICMPv6 message MUST ONLY be used with ILNPv6 sessions.
本节中描述的ICMPv6消息具有ICMP类型156，仅用于当前ILNPv6会话。此消息使ILNPv6节点能够通知ILNPv6对应节点对发起此消息的ILNPv6节点的活动定位器集所做的更改。此特定ICMPv6消息只能用于ILNPv6会话。
This particular ICMPv6 message MUST ONLY be used with ILNPv6 sessions. The Checksum field for this message is calculated identically as for any other ICMPv6 message.
此特定ICMPv6消息只能用于ILNPv6会话。此消息的校验和字段的计算方法与任何其他ICMPv6消息相同。
ICMPv6 Locator Update message
ICMPv6定位器更新消息
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Locs | Operation | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Locator [1] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference [1] | Lifetime [1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Locator [2] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference [2] | Lifetime [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Locs | Operation | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Locator [1] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference [1] | Lifetime [1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Locator [2] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference [2] | Lifetime [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
ICMPv6 Locator Update fields:
ICMPv6定位器更新字段：
Type 156
156型
Code 0
代码0
Checksum The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum field is set to 0.
校验和ICMP消息的补码和的16位补码，从ICMP类型开始。为了计算校验和，校验和字段设置为0。
Num of Locs The number of 64-bit Locator values that are advertised in this message. This field MUST NOT be zero.
Num of LOC此消息中公布的64位定位器值的数量。此字段不能为零。
Locator[i], The 64-bit Locator values currently i = 1..Num of Locs valid for the sending ILNPv6 node.
Locator[i]，64位定位器值当前i=1..Num对于发送ILNPv6节点有效的LOC。
Preference[i], The preferability of each Locator[i], i = 1..Num of Locs relative to other valid Locator[i] values. The Preference numbers here are identical, both in syntax and semantics, to the Preference values for L64 records as specified by [RFC6742].
首选项[i]，每个定位器[i]的首选项，i=1..Num相对于其他有效定位器[i]值的LOC。此处的首选项编号在语法和语义上与[RFC6742]指定的L64记录的首选项值相同。
Lifetime[i] The maximum number of seconds that this i = 1..Num of Locs particular Locator may be considered valid. Normally, this is identical to the DNS lifetime of the corresponding L64 record, if one exists.
寿命[i]此i=1..Num Locs特定定位器被视为有效的最大秒数。通常，这与相应L64记录（如果存在）的DNS生存期相同。
Operation The value in this field indicates whether this is a Locator Update Advertisement (0x01) or a Locator Update Acknowledgement (0x02).
操作此字段中的值指示这是定位器更新公告（0x01）还是定位器更新确认（0x02）。
RESERVED A field reserved for possible future use. At present, the sender MUST initialise this field to zero. Receivers should ignore this field at present. The field might be used for some protocol function in future.
保留为将来可能使用而保留的字段。目前，发送方必须将此字段初始化为零。目前，接收者应忽略此字段。该字段将来可能用于某些协议功能。
The Operation field has value 1 (hexadecimal 0x01) for a Locator Update Advertisement. The Operation field has value 2 (hexadecimal 0x02) for a Locator Update Acknowledgement. All other values of the Operation field are reserved for future use by future revisions of this specification.
对于定位器更新播发，操作字段的值为1（十六进制0x01）。对于定位器更新确认，操作字段的值为2（十六进制0x02）。操作字段的所有其他值保留供本规范未来版本使用。
A node whose set of valid Locators has changed MUST send Locator Update Advertisement messages to each correspondent node for each active unicast ILNP session. For unicast ILNP sessions, the receiver of a valid Locator Update Advertisement (e.g., authentication checks all passed; advertisement is received from a current correspondent node) addressed to the receiver MUST send a Locator Update Acknowledgement back to the sender of the Locator Update Advertisement. The Acknowledgement message body is identical to the received Advertisement message body, except for the Operation value.
有效定位器集已更改的节点必须为每个活动单播ILNP会话向每个对应节点发送定位器更新播发消息。对于单播ILNP会话，发往接收者的有效定位器更新公告（例如，认证检查全部通过；从当前对应节点接收公告）的接收者必须将定位器更新确认发送回定位器更新公告的发送者。除了操作值之外，确认消息正文与接收到的广告消息正文相同。
All ILNPv6 ICMP Locator Update messages MUST contain a valid ILNPv6 Identifier option and MUST contain an ILNPv6 Nonce Option.
所有ILNPv6 ICMP定位器更新消息必须包含有效的ILNPv6标识符选项，并且必须包含ILNPv6 Nonce选项。
ILNPv6 ICMP Locator Update messages also MAY be protected using IP Security for ILNP [RFC6741] [RFC4301]. Deployments in high-threat environments SHOULD also protect ILNPv6 ICMP Locator Update messages using IPsec. While IPsec Encapsulating Security Payload (ESP) can protect a payload, no form of IPsec ESP is able to protect an IPv6 option that appears prior to the ESP header.
ILNPv6 ICMP定位器更新消息也可以使用ILNP[RFC6741][RFC4301]的IP安全性进行保护。在高威胁环境中的部署还应使用IPsec保护ILNPv6 ICMP定位器更新消息。虽然IPsec封装安全有效负载（ESP）可以保护有效负载，但任何形式的IPsec ESP都无法保护出现在ESP头之前的IPv6选项。
Note that even when IP Security for ILNP is in use, the ILNP Nonce Option still MUST be present. This simplifies protocol processing, and it also means that a receiver can perform the inexpensive check of the Nonce value before performing any (potentially expensive) cryptographic calculation.
请注意，即使在使用ILNP的IP安全性时，ILNP Nonce选项仍然必须存在。这简化了协议处理，也意味着接收器可以在执行任何（可能昂贵的）加密计算之前执行Nonce值的廉价检查。
This example shows the ICMPv6 syntax for the case where 2 Locator values are being indicated.
此示例显示了指示2个定位器值的情况下的ICMPv6语法。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Locs | RESERVED | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Locator [1] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference [1] | Lifetime [1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Locator [2] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference [2] | Lifetime [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Locs | RESERVED | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Locator [1] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference [1] | Lifetime [1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Locator [2] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference [2] | Lifetime [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message has no impact on any transport protocol.
此消息对任何传输协议都没有影响。
The message may affect where packets for a given transport-layer session are sent, but an ILNP design objective is to decouple transport-layer protocols and transport-layer session information from network-layer changes.
消息可能会影响给定传输层会话的数据包的发送位置，但ILNP的设计目标是将传输层协议和传输层会话信息与网络层更改分离。
Implementers may use any internal implementation they wish, provided that the external appearance is the same as this implementation approach.
只要外部外观与此实现方法相同，实现者可以使用他们希望的任何内部实现。
To support ILNPv6, and to retain the incremental deployability and backwards compatibility needed, the network layer needs a mode bit in the Transport Control Block (or its equivalent) to track which IP sessions are using the classic IPv6 mode and which IP sessions are using the Identifier/Locator Split mode.
为了支持ILNPv6，并保持所需的增量部署能力和向后兼容性，网络层需要传输控制块（或其等效物）中的模式位来跟踪哪些IP会话使用经典IPv6模式，哪些IP会话使用标识符/定位器拆分模式。
Further, when supporting ILNPv4, nodes will need to support an Identifier Locator Communication Cache (ILCC) in the network layer as described in [RFC6741].
此外，当支持ILNPv4时，节点将需要在网络层中支持标识符定位器通信缓存（ILCC），如[RFC6741]中所述。
A node sending an ICMP Locator Update message MUST include all currently valid Locator values in that message. A node receiving a valid ICMP Locator Update message MUST replace the previously current set of Locator values for that correspondent node in its own ILCC with the newly received set of Locator values.
发送ICMP定位器更新消息的节点必须在该消息中包含所有当前有效的定位器值。接收到有效ICMP定位器更新消息的节点必须用新接收到的定位器值集替换其自身ILCC中对应节点的先前当前定位器值集。
Every implementation needs to support a large number of Locator values being sent or received in a single ICMP Locator Update message, because a multihomed node or multihomed site might have a large number of upstream links to different service providers, each with its own Locator value.
每个实现都需要支持在单个ICMP定位器更新消息中发送或接收大量定位器值，因为多宿节点或多宿站点可能有大量到不同服务提供商的上游链接，每个都有自己的定位器值。
This ICMPv6 message uses the same checksum calculations as any other ICMPv6 message.
此ICMPv6消息使用与任何其他ICMPv6消息相同的校验和计算。
When ILNPv6 is not in use, the receiving IPv6 mode MUST discard the ICMP Locator Update packet without processing the packet. This is standard behaviour for a non-ILNPv6 node when receiving an ICMPv6 message with an unknown header field value.
当ILNPv6未使用时，接收IPv6模式必须丢弃ICMP定位器更新数据包，而不处理该数据包。这是非ILNPv6节点在接收具有未知标头字段值的ICMPv6消息时的标准行为。
Security considerations for the overall ILNP architecture are described in [RFC6740]. Additional common security considerations are described in [RFC6741]. This section describes security considerations specific to ILNPv6 topics discussed in this document.
[RFC6740]中描述了整个ILNP体系结构的安全注意事项。[RFC6741]中描述了其他常见安全注意事项。本节介绍本文档中讨论的ILNPv6主题的特定安全注意事项。
The ICMPv6 Locator Update message MUST ONLY be used for ILNPv6 sessions.
ICMPv6定位器更新消息只能用于ILNPv6会话。
The ILNP Nonce Destination Option [RFC6744] MUST be present in packets containing an ICMPv6 Locator Update message. Further, the received Nonce Destination Option MUST contain the correct nonce value for the packet to be accepted by the recipient and then passed to the ICMPv6 protocol for processing. If either of these requirements are not met, the received packet MUST be discarded as a forgery, and a security event SHOULD be logged by the system receiving the non-authentic packet.
ILNP Nonce Destination选项[RFC6744]必须存在于包含ICMPv6定位器更新消息的数据包中。此外，接收的Nonce Destination选项必须包含正确的Nonce值，以便接收方接受数据包，然后将其传递给ICMPv6协议进行处理。如果不满足这些要求中的任何一个，则必须将收到的数据包作为伪造品丢弃，并且接收非真实数据包的系统应记录安全事件。
ILNP sessions operating in higher risk environments SHOULD use IP Security for ILNP [RFC6741] [RFC4301] *in addition* to the ILNPv6 Nonce Destination Option. Use of IP Security for ILNP to protect a packet does NOT permit the packet to be sent without the Nonce Destination Option.
在高风险环境中运行的ILNP会话应为ILNP[RFC6741][RFC4301]*使用IP安全性，此外*还应使用ILNPv6 Nonce Destination选项。对ILNP使用IP安全性来保护数据包不允许在没有Nonce Destination选项的情况下发送数据包。
Implementations need to support the case where a single ICMP Locator Update message contains a large number of Locator and Preference values and ought not develop a security fault (e.g., stack overflow) due to a received message containing more Locator values than expected.
实现需要支持以下情况：单个ICMP定位器更新消息包含大量定位器和首选项值，并且不应由于接收到的消息包含比预期更多的定位器值而产生安全故障（例如，堆栈溢出）。
If the ILNP Nonce value is predictable, then an off-path attacker might be able to forge data or control packets. This risk also is mitigated by the existing common practice of IP Source Address filtering [RFC2827] [RFC3704].
如果ILNP Nonce值是可预测的，则非路径攻击者可能能够伪造数据或控制数据包。IP源地址过滤[RFC2827][RFC3704]的现有常见做法也减轻了此风险。
Consistent with the procedures of [RFC4443], IANA has assigned the value 156 to the ICMP Type listed in Section 2.
根据[RFC4443]中的程序，IANA已将值156分配给第2节中列出的ICMP类型。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年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月。
[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月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年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月。
[RFC6742] Atkinson, R., Bhatti, S. and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, November 2012.
[RFC6742]Atkinson，R.，Bhatti，S.和S.Rose，“标识符定位器网络协议（ILNP）的DNS资源记录”，RFC 67422012年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.
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 KY16 9SX Scotland, UK
SN BaTHI计算机学院圣·安驻斯大学北HAUH，圣安德鲁斯FIFE KY16 9SX苏格兰，英国
EMail: saleem@cs.st-andrews.ac.uk
EMail: saleem@cs.st-andrews.ac.uk