Internet Engineering Task Force (IETF) M. Stenberg
Request for Comments: 7788 S. Barth
Category: Standards Track Independent
ISSN: 2070-1721 P. Pfister
Cisco Systems
April 2016
Internet Engineering Task Force (IETF) M. Stenberg
Request for Comments: 7788 S. Barth
Category: Standards Track Independent
ISSN: 2070-1721 P. Pfister
Cisco Systems
April 2016
Home Networking Control Protocol
家庭网络控制协议
Abstract
摘要
This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.
本文档描述了家庭网络控制协议（HNCP），一种可扩展的配置协议，以及家庭网络设备的一组要求。HNCP被描述为分布式节点共识协议（DNCP）的概要文件和扩展。HNCP支持发现网络边界、自动配置地址、名称解析、服务发现，以及使用支持基于源地址和目标地址的路由的任何路由协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7788.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7788.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7
4. HNCP Versioning and Router Capabilities . . . . . . . . . . . 9
5. Interface Classification . . . . . . . . . . . . . . . . . . 9
5.1. Interface Categories . . . . . . . . . . . . . . . . . . 9
5.2. DHCP-Aided Auto-Detection . . . . . . . . . . . . . . . . 10
5.3. Algorithm for Border Discovery . . . . . . . . . . . . . 11
6. Autonomous Address Configuration . . . . . . . . . . . . . . 12
6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. External Connections . . . . . . . . . . . . . . . . . . 13
6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 14
6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 14
6.3.2. Making New Assignments . . . . . . . . . . . . . . . 16
6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 17
6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 17
6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 17
6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 18
7. Configuration of Hosts and Non-HNCP Routers . . . . . . . . . 19
7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19
7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 20
7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20
7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 21
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 21
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7
4. HNCP Versioning and Router Capabilities . . . . . . . . . . . 9
5. Interface Classification . . . . . . . . . . . . . . . . . . 9
5.1. Interface Categories . . . . . . . . . . . . . . . . . . 9
5.2. DHCP-Aided Auto-Detection . . . . . . . . . . . . . . . . 10
5.3. Algorithm for Border Discovery . . . . . . . . . . . . . 11
6. Autonomous Address Configuration . . . . . . . . . . . . . . 12
6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. External Connections . . . . . . . . . . . . . . . . . . 13
6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 14
6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 14
6.3.2. Making New Assignments . . . . . . . . . . . . . . . 16
6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 17
6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 17
6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 17
6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 18
7. Configuration of Hosts and Non-HNCP Routers . . . . . . . . . 19
7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19
7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 20
7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20
7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 21
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 21
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22
10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 23
10.1. HNCP-Version TLV . . . . . . . . . . . . . . . . . . . . 23
10.2. External-Connection TLV . . . . . . . . . . . . . . . . 24
10.2.1. Delegated-Prefix TLV . . . . . . . . . . . . . . . . 25
10.2.2. DHCPv6-Data TLV . . . . . . . . . . . . . . . . . . 27
10.2.3. DHCPv4-Data TLV . . . . . . . . . . . . . . . . . . 27
10.3. Assigned-Prefix TLV . . . . . . . . . . . . . . . . . . 28
10.4. Node-Address TLV . . . . . . . . . . . . . . . . . . . . 29
10.5. DNS-Delegated-Zone TLV . . . . . . . . . . . . . . . . . 30
10.6. Domain-Name TLV . . . . . . . . . . . . . . . . . . . . 31
10.7. Node-Name TLV . . . . . . . . . . . . . . . . . . . . . 31
10.8. Managed-PSK TLV . . . . . . . . . . . . . . . . . . . . 32
11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
12.1. Interface Classification . . . . . . . . . . . . . . . . 34
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 35
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 23
10.1. HNCP-Version TLV . . . . . . . . . . . . . . . . . . . . 23
10.2. External-Connection TLV . . . . . . . . . . . . . . . . 24
10.2.1. Delegated-Prefix TLV . . . . . . . . . . . . . . . . 25
10.2.2. DHCPv6-Data TLV . . . . . . . . . . . . . . . . . . 27
10.2.3. DHCPv4-Data TLV . . . . . . . . . . . . . . . . . . 27
10.3. Assigned-Prefix TLV . . . . . . . . . . . . . . . . . . 28
10.4. Node-Address TLV . . . . . . . . . . . . . . . . . . . . 29
10.5. DNS-Delegated-Zone TLV . . . . . . . . . . . . . . . . . 30
10.6. Domain-Name TLV . . . . . . . . . . . . . . . . . . . . 31
10.7. Node-Name TLV . . . . . . . . . . . . . . . . . . . . . 31
10.8. Managed-PSK TLV . . . . . . . . . . . . . . . . . . . . 32
11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
12.1. Interface Classification . . . . . . . . . . . . . . . . 34
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 35
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
The Home Networking Control Protocol (HNCP) is designed to facilitate the sharing of state among home routers to fulfill the needs of the IPv6 homenet architecture [RFC7368], which assumes zero-configuration operation, multiple subnets, multiple home routers, and (potentially) multiple upstream service providers providing (potentially) multiple prefixes to the home network. While RFC 7368 sets no requirements for IPv4 support, HNCP aims to support the dual-stack mode of operation, and therefore the functionality is designed with that in mind. The state is shared as TLVs transported in the DNCP node state among the routers (and potentially advanced hosts) to enable:
家庭网络控制协议（HNCP）旨在促进家庭路由器之间的状态共享，以满足IPv6家庭网络体系结构[RFC7368]的需求，该体系结构假设零配置操作、多个子网、多个家庭路由器和（可能）多个上游服务提供商（可能）提供家庭网络的多个前缀。虽然RFC 7368对IPv4支持没有任何要求，但HNCP的目标是支持双栈操作模式，因此功能的设计考虑到了这一点。该状态在路由器（以及可能的高级主机）之间共享为以DNCP节点状态传输的TLV，以启用：
o Autonomic discovery of network borders (Section 5.3) based on Distributed Node Consensus Protocol (DNCP) topology.
o 基于分布式节点一致性协议（DNCP）拓扑的网络边界自主发现（第5.3节）。
o Automated portioning of prefixes delegated by the service providers as well as assigned prefixes to both HNCP and non-HNCP routers (Section 6.3) using [RFC7695]. Prefixes assigned to HNCP routers are used to:
o 使用[RFC7695]自动分配服务提供商委派的前缀以及分配给HNCP和非HNCP路由器的前缀（第6.3节）。分配给HNCP路由器的前缀用于：
* Provide addresses to non-HNCP aware nodes (using Stateless Address Autoconfiguration (SLAAC) and DHCP).
* 向非HNCP感知节点提供地址（使用无状态地址自动配置（SLAAC）和DHCP）。
* Provide space in which HNCP nodes assign their own addresses (Section 6.4).
* 提供HNCP节点分配自己地址的空间（第6.4节）。
o Internal and external name resolution, as well as multi-link service discovery (Section 8).
o 内部和外部名称解析，以及多链路服务发现（第8节）。
o Other services not defined in this document that do need to share state among homenet nodes and do not cause rapid and constant TLV changes (see the following applicability section).
o 本文档中未定义的其他服务确实需要在homenet节点之间共享状态，并且不会导致TLV的快速和持续更改（请参见以下适用性部分）。
HNCP is a protocol based on DNCP [RFC7787] and includes a DNCP profile that defines transport and synchronization details for sharing state across nodes defined in Section 3. The rest of the document defines behavior of the services noted above, how the required TLVs are encoded (Section 10), as well as additional requirements on how HNCP nodes should behave (Section 11).
HNCP是一种基于DNCP[RFC7787]的协议，包括一个DNCP配置文件，该配置文件定义了在第3节中定义的节点之间共享状态的传输和同步细节。本文档的其余部分定义了上述服务的行为、所需TLV的编码方式（第10节）以及HNCP节点行为的其他要求（第11节）。
While HNCP does not deal with routing protocols directly (except potentially informing them about internal and external interfaces if classification specified in Section 5.3 is used), in homenet environments where multiple IPv6 source prefixes can be present, routing based on the source and destination address is necessary [RFC7368]. Ideally, the routing protocol is also zero configuration (e.g., no need to configure identifiers or metrics), although HNCP can also be used with a manually configured routing protocol.
虽然HNCP不直接处理路由协议（除非在使用第5.3节中规定的分类时可能会通知他们内部和外部接口），但在可以存在多个IPv6源前缀的homenet环境中，基于源地址和目标地址的路由是必要的[RFC7368]。理想情况下，路由协议也是零配置（例如，不需要配置标识符或度量），尽管HNCP也可以与手动配置的路由协议一起使用。
As HNCP uses DNCP as the actual state synchronization protocol, the applicability statement of DNCP applies here as well; HNCP should not be used for any data that changes rapidly and constantly. If such data needs to be published in an HNCP network, 1) a more applicable protocol should be used for those portions, and 2) locators to a server of said protocol should be announced using HNCP instead. An example for this is naming and service discovery (Section 8) for which HNCP only transports DNS server addresses and no actual per-name or per-service data of hosts.
由于HNCP使用DNCP作为实际状态同步协议，因此DNCP的适用性声明也适用于此；HNCP不应用于任何快速且持续变化的数据。如果需要在HNCP网络中发布此类数据，1）应为这些部分使用更适用的协议，2）应使用HNCP来公布到所述协议服务器的定位器。例如，命名和服务发现（第8节），HNCP仅传输DNS服务器地址，而不传输主机的实际每个名称或每个服务数据。
HNCP TLVs specified within this document, in steady state, stay constant, with one exception: as Delegated-Prefix TLVs (Section 10.2.1) do contain lifetimes, they force republishing of that data every time the valid or preferred lifetimes of prefixes are updated (significantly). Therefore, it is desirable for ISPs to provide large enough valid and preferred lifetimes to avoid unnecessary HNCP state churn in homes, but even given non-cooperating ISPs, the state churn is proportional only to the number of externally received delegated prefixes and not to the home network size, and it should therefore be relatively low.
本文件中规定的HNCP TLV在稳定状态下保持不变，但有一个例外：由于委托前缀TLV（第10.2.1节）确实包含使用寿命，因此每次更新前缀的有效或首选使用寿命时，它们都会强制重新发布该数据（显著）。因此，希望ISP提供足够大的有效和首选生存期，以避免家庭中不必要的HNCP状态波动，但即使给定非合作ISP，状态波动也仅与外部接收的委派前缀数量成比例，而不是与家庭网络大小成比例，因此应相对较低。
HNCP assumes a certain level of control over host configuration servers (e.g., DHCP [RFC2131]) on links that are managed by its routers. Some HNCP functionality (such as border discovery or some aspects of naming) might be affected by existing DHCP servers that are not aware of the HNCP-managed network and thus might need to be reconfigured to not result in unexpected behavior.
HNCP假定对其路由器管理的链路上的主机配置服务器（例如DHCP[RFC2131]）具有一定程度的控制。某些HNCP功能（如边界发现或命名的某些方面）可能会受到现有DHCP服务器的影响，这些服务器不知道HNCP管理的网络，因此可能需要重新配置以避免出现意外行为。
While HNCP routers can provide configuration to and receive configuration from non-HNCP routers, they are not able to traverse such devices based solely on the protocol as defined in this document, i.e., HNCP routers that are connected only by different interfaces of a non-HNCP router will not be part of the same HNCP network.
虽然HNCP路由器可以向非HNCP路由器提供配置并接收来自非HNCP路由器的配置，但它们不能仅基于本文件中定义的协议遍历此类设备，即，仅通过非HNCP路由器的不同接口连接的HNCP路由器将不属于同一HNCP网络。
While HNCP is designed to be used by (home) routers, it can also be used by advanced hosts that want to do, e.g., their own address assignment and routing.
虽然HNCP设计用于（家庭）路由器，但它也可用于想要执行的高级主机，例如，它们自己的地址分配和路由。
HNCP is link-layer agnostic; if a link supports IPv6 (link-local) multicast and unicast, HNCP will work on it. Trickle retransmissions and keep-alives will handle both packet loss and non-transitive connectivity, ensuring eventual convergence.
HNCP是链路层不可知的；如果链路支持IPv6（链路本地）多播和单播，HNCP将在其上工作。涓流重传和保持有效将处理数据包丢失和非传递连接，确保最终的收敛。
The following terms are used as they are defined in [RFC7695]:
使用[RFC7695]中定义的下列术语：
o Advertised Prefix Priority
o 播发前缀优先级
o Advertised Prefix
o 广告前缀
o Assigned Prefix
o 指定前缀
o Delegated Prefix
o 委托前缀
o Prefix Adoption
o 前缀采用
o Private Link
o 专用链路
o Published Assigned Prefix
o 已发布的指定前缀
o Applied Assigned Prefix
o 应用指定前缀
o Shared Link
o 共享链接
The following terms are used as they are defined in [RFC7787]:
使用[RFC7787]中定义的下列术语：
o DNCP profile
o DNCP剖面图
o Node identifier
o 节点标识符
o Link
o 链接
o Interface
o 界面
(HNCP) node a device implementing this specification.
（HNCP）节点实现本规范的设备。
(HNCP) router a device implementing this specification, which forwards traffic on behalf of other devices.
（HNCP）路由器实现本规范的设备，代表其他设备转发流量。
Greatest node when comparing the DNCP node identifiers of identifier multiple nodes, the one that has the greatest value in a bitwise comparison.
最大节点比较标识符多个节点的DNCP节点标识符时，按位比较中具有最大值的节点。
Border separation point between administrative domains; in this case, between the home network and any other network, i.e., usually an ISP network.
行政领域之间的边界分隔点；在这种情况下，在家庭网络和任何其他网络之间，即通常是ISP网络。
Internal link a link that does not cross borders.
内部链接不跨越边界的链接。
Internal an interface that is connected to an internal link. interface
内部连接到内部链接的接口。界面
External an interface that is connected to a link that is interface not an internal link.
外部接口连接到不是内部链接的链接的接口。
Interface a local configuration denoting the use of a category particular interface. The Interface category determines how an HNCP node should treat the particular interface. The External and Internal categories mark the interface as out of or within the network border; there are also a number of subcategories of Internal that further affect local node behavior. See Section 5.1 for a list of interface categories and how they behave. The Internal or External category may also be auto-detected (Section 5.3).
接口表示使用特定接口的本地配置。接口类别确定HNCP节点应如何处理特定接口。外部和内部类别将接口标记为在网络边界之外或之内；还有许多内部节点的子类别会进一步影响本地节点的行为。有关接口类别及其行为的列表，请参见第5.1节。内部或外部类别也可自动检测（第5.3节）。
Border router a router announcing external connectivity and forwarding traffic across the network border.
边界路由器宣布外部连接并跨网络边界转发流量的路由器。
Common Link a set of nodes on a link that share a common view of it, i.e., they see each other's traffic and the same set of hosts. Unless configured otherwise, transitive connectivity is assumed.
公共链路链路上共享公共视图的一组节点，即它们可以看到彼此的通信量和同一组主机。除非另有配置，否则假定为可传递连接。
DHCPv4 refers to the Dynamic Host Configuration Protocol [RFC2131] in this document.
DHCPv4是指本文档中的动态主机配置协议[RFC2131]。
DHCPv6 refers to the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] in this document.
DHCPv6是指本文档中针对IPv6的动态主机配置协议（DHCPv6）[RFC3315]。
DHCP refers to cases that apply to both DHCPv4 and DHCPv6 in this document.
DHCP指本文档中适用于DHCPv4和DHCPv6的情况。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
The DNCP profile for HNCP is defined as follows:
HNCP的DNCP配置文件定义如下：
o HNCP uses UDP datagrams on port 8231 as a transport over link-local scoped IPv6, using unicast and multicast (FF02:0:0:0:0:0:0:11 is the HNCP group address). Received datagrams where either or both of the IPv6 source or destination addresses are not link-local scoped MUST be ignored. Replies to multicast and unicast messages MUST be sent to the IPv6 source address and port of the original message. Each node MUST be able to receive (and potentially reassemble) UDP datagrams with a payload of at least 4000 bytes.
o HNCP使用端口8231上的UDP数据报作为链路本地作用域IPv6上的传输，使用单播和多播（FF02:0:0:0:0:11是HNCP组地址）。必须忽略接收到的数据报，其中IPv6源地址或目标地址中的一个或两个都不是链路本地作用域。对多播和单播消息的答复必须发送到原始消息的IPv6源地址和端口。每个节点必须能够接收（并可能重新组合）负载至少为4000字节的UDP数据报。
o HNCP operates on multicast-capable interfaces only. HNCP nodes MUST assign a non-zero 32-bit endpoint identifier to each interface for which HNCP is enabled. The value 0 is not used in DNCP TLVs but has a special meaning in HNCP TLVs (see Sections 6.4 and 10.3). These identifiers MUST be locally unique within the scope of the node, and using values equivalent to the IPv6 link-local scope identifiers for the given interfaces are RECOMMENDED.
o HNCP仅在支持多播的接口上运行。HNCP节点必须为启用HNCP的每个接口分配一个非零32位端点标识符。数值0未在DNCP TLV中使用，但在HNCP TLV中具有特殊含义（见第6.4节和第10.3节）。这些标识符在节点范围内必须是本地唯一的，建议为给定接口使用等同于IPv6链路本地范围标识符的值。
o HNCP uses opaque 32-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP SHOULD use a random node identifier. If there is a node identifier collision (as specified in the Node-State TLV handling of Section 4.4 of [RFC7787]), the node MUST immediately generate
o HNCP使用不透明的32位节点标识符（DNCP_node_IDENTIFIER_LENGTH=32）。实现HNCP的节点应使用随机节点标识符。如果存在节点标识符冲突（如[RFC7787]第4.4节节点状态TLV处理中所述），则节点必须立即生成
and use a new random node identifier that is not used by any other node at the time, based on the current DNCP network state.
并基于当前DNCP网络状态，使用当时未被任何其他节点使用的新随机节点标识符。
o HNCP nodes MUST use the leading 64 bits of the MD5 message digest [RFC1321] as the DNCP hash function H(x) used in building the DNCP hash tree.
o HNCP节点必须使用MD5消息摘要[RFC1321]的前导64位作为用于构建DNCP哈希树的DNCP哈希函数H（x）。
o HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on all endpoints. The following parameters are suggested:
o HNCP节点必须在所有端点上使用DNCP的每端点保持活动扩展。建议使用以下参数：
* Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20 seconds.
* 默认保持活动时间间隔（DNCP\U保持活动时间间隔）：20秒。
* Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually lossless links works fine, as it allows for one lost keep-alive. If used on a lossy link, a considerably higher multiplier, such as 15, should be used instead. In that case, an implementation might prefer shorter keep-alive intervals on that link as well to ensure that the timeout (equal to DNCP_KEEPALIVE_INTERVAL * DNCP_KEEPALIVE_MULTIPLIER) after which entirely lost nodes time out is low enough.
* 乘数（DNCP_KEEPALIVE_乘数）：2.1在几乎无损的链接上运行良好，因为它允许一个丢失的保持活动。如果在有损链路上使用，则应使用相当高的乘数，如15。在这种情况下，实现可能更希望该链路上的保持活动时间间隔更短，以确保超时（等于DNCP_KEEPALIVE_INTERVAL*DNCP_KEEPALIVE_乘数），在此之后完全丢失的节点超时足够低。
o HNCP nodes use the following Trickle parameters for the per-interface Trickle instances:
o HNCP节点对每个接口涓流实例使用以下涓流参数：
* k SHOULD be 1, as the timer reset when data is updated, and further retransmissions should handle packet loss. Even on a non-transitive lossy link, the eventual per-endpoint keep-alives should ensure status synchronization occurs.
* k应为1，因为数据更新时计时器重置，进一步的重新传输应处理数据包丢失。即使在非传递有损链路上，最终的每端点保持有效也应确保发生状态同步。
* Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: earliest transmissions may occur at Imin / 2.
* Imin应为200毫秒，但不得低于200毫秒。注：最早的传输可能发生在Imin/2。
* Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be lower.
* Imax应为Imin[RFC6206]的7倍，但不得低于Imin。
o HNCP unicast traffic SHOULD be secured using Datagram Transport Layer Security (DTLS) [RFC6347] as described in DNCP if exchanged over unsecured links. UDP on port 8232 is used for this purpose. A node implementing HNCP security MUST support the DNCP Pre-Shared Key (PSK) method, SHOULD support the PKI-based trust method, and MAY support the DNCP certificate-based trust consensus method. [RFC7525] provides guidance on how to securely utilize DTLS.
o 如果通过不安全链路交换，HNCP单播通信应使用数据报传输层安全性（DTLS）[RFC6347]进行保护，如DNCP中所述。端口8232上的UDP用于此目的。实现HNCP安全的节点必须支持DNCP预共享密钥（PSK）方法，应该支持基于PKI的信任方法，并且可以支持基于DNCP证书的信任协商方法。[RFC7525]提供了有关如何安全使用DTL的指导。
o HNCP nodes MUST ignore all Node-State TLVs received via multicast on a link that has DNCP security enabled in order to prevent spoofing of node state changes.
o HNCP节点必须忽略在启用了DNCP安全性的链路上通过多播接收的所有节点状态TLV，以防止对节点状态更改的欺骗。
Multiple versions of HNCP based on compatible DNCP profiles may be present in the same network when transitioning between HNCP versions, and for troubleshooting purposes, it might be beneficial to identify the HNCP agent version running. Therefore, each node MUST include an HNCP-Version TLV (Section 10.1) indicating the currently supported version in its node data and MUST ignore (except for DNCP synchronization purposes) any TLVs that have a type greater than 32 and that are published by nodes that didn't also publish an HNCP-Version TLV.
在HNCP版本之间转换时，同一网络中可能存在基于兼容DNCP配置文件的多个HNCP版本，出于故障排除目的，识别正在运行的HNCP代理版本可能是有益的。因此，每个节点必须在其节点数据中包含HNCP版本TLV（第10.1节），指示当前支持的版本，并且必须忽略（DNCP同步目的除外）类型大于32且由未发布HNCP版本TLV的节点发布的任何TLV。
HNCP routers may also have different capabilities regarding interactions with hosts, e.g., for configuration or service discovery. These are indicated by M, P, H, and L values. The combined "capability value" is a metric indicated by interpreting the bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These values are used to elect certain servers on a Common Link, as described in Section 7. Nodes that are not routers MUST announce the value 0 for all capabilities. Any node announcing the value 0 for a capability is considered to not advertise said capability and thus does not take part in the respective election.
HNCP路由器在与主机的交互方面也可能具有不同的功能，例如用于配置或服务发现。这些由M、P、H和L值表示。组合的“能力值”是通过将位解释为整数表示的度量，即（M<12 | P<8 | H<4 | L）。这些值用于选择公共链路上的某些服务器，如第7节所述。非路由器的节点必须为所有功能宣布值0。宣布某一能力的值0的任何节点都被视为不公布所述能力，因此不参与相应的选择。
HNCP specifies the following categories that interfaces can be configured to be in:
HNCP指定了可配置接口的以下类别：
Internal category: This declares an interface to be internal, i.e., within the borders of the HNCP network. The interface MUST operate as a DNCP endpoint. Routers MUST forward traffic with appropriate source addresses between their internal interfaces and allow internal traffic to reach external networks. All nodes MUST implement this category, and nodes not implementing any other category implicitly use it as a fixed default.
内部类别：该类别将接口声明为内部接口，即在HNCP网络的边界内。接口必须作为DNCP端点运行。路由器必须在其内部接口之间转发具有适当源地址的流量，并允许内部流量到达外部网络。所有节点都必须实现该类别，而未实现任何其他类别的节点隐式地将其用作固定默认值。
External category: This declares an interface to be external, i.e., not within the borders of the HNCP network. The interface MUST NOT operate as a DNCP endpoint. Accessing internal resources from external interfaces is restricted, i.e., the use of Recommended Simple Security Capabilities in Customer Premises Equipments (CPEs) [RFC6092] is RECOMMENDED. HNCP routers SHOULD announce acquired configuration information for use in the network as described in Section 6.2, if the interface appears to be connected to an external network. HNCP routers MUST implement this category.
外部类别：该类别将接口声明为外部接口，即不在HNCP网络的边界内。接口不能作为DNCP端点运行。从外部接口访问内部资源受到限制，即建议在客户场所设备（CPE）[RFC6092]中使用推荐的简单安全功能。如果接口似乎连接到外部网络，HNCP路由器应按照第6.2节所述公布获取的配置信息，以便在网络中使用。HNCP路由器必须实现这一类别。
Leaf category: This declares an interface used by client devices only. Such an interface uses the Internal category with the exception that it MUST NOT operate as a DNCP endpoint. This category SHOULD be supported by HNCP routers.
叶类别：这声明了一个仅由客户端设备使用的接口。此类接口使用内部类别，但不能作为DNCP端点运行。HNCP路由器应支持此类别。
Guest category: This declares an interface used by untrusted client devices only. In addition to the restrictions of the Leaf category, HNCP routers MUST filter traffic from and to the interface such that connected devices are unable to reach other devices inside the HNCP network or query services advertised by them unless explicitly allowed. This category SHOULD be supported by HNCP routers.
来宾类别：这声明了一个仅由不受信任的客户端设备使用的接口。除了叶类别的限制外，HNCP路由器必须过滤来自接口和到接口的流量，以使连接的设备无法到达HNCP网络内的其他设备或查询其发布的服务，除非明确允许。HNCP路由器应支持此类别。
Ad Hoc category: This configures an interface to use the Internal category, but no assumption is made about the link's transitivity. All other interface categories assume transitive connectivity. This affects the Common Link (Section 6.1) definition. Support for this category is OPTIONAL.
特设类别：这将配置一个接口以使用内部类别，但不假设链接的可传递性。所有其他接口类别都假定可传递连接。这会影响公共链接（第6.1节）的定义。对该类别的支持是可选的。
Hybrid category: This declares an interface to use the Internal category while still trying to acquire (external) configuration information on it, e.g., by running DHCP clients. This is useful, e.g., if the link is shared with a non-HNCP router under control and still within the borders of the same network. Detection of this category automatically in addition to manual configuration is out of scope of this document. Support for this category is OPTIONAL.
Hybrid category（混合类别）：这声明了一个使用内部类别的接口，同时仍试图获取内部类别上的（外部）配置信息，例如，通过运行DHCP客户端。这是有用的，例如，如果链路与受控制且仍在同一网络边界内的非HNCP路由器共享。除手动配置外，自动检测此类不在本文档范围内。对该类别的支持是可选的。
Auto-detection of interface categories is possible based on interaction with DHCPv4 [RFC2131] and DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] servers on connected links. HNCP defines special DHCP behavior to differentiate its internal servers from external ones in order to achieve this. Therefore, all internal devices (including HNCP nodes) running DHCP servers on links where auto-detection is used by any HNCP node MUST use the following mechanism based on "The User Class Option for DHCP" [RFC3004] and its DHCPv6 counterpart [RFC3315]:
基于与连接链路上的DHCPv4[RFC2131]和DHCPv6前缀委派（DHCPv6 PD）[RFC3633]服务器的交互，可以自动检测接口类别。HNCP定义了特殊的DHCP行为，以区分其内部服务器和外部服务器，从而实现这一点。因此，在任何HNCP节点使用自动检测的链路上运行DHCP服务器的所有内部设备（包括HNCP节点）必须基于“DHCP的用户类选项”[RFC3004]及其DHCPv6对应项[RFC3315]使用以下机制：
o The device MUST ignore or reject DHCP-Requests containing a DHCP user class consisting of the ASCII string "HOMENET".
o 设备必须忽略或拒绝包含由ASCII字符串“HOMENET”组成的DHCP用户类的DHCP请求。
Not following this rule (e.g., running unmodified DHCP servers) might lead to false positives when auto-detection is used, i.e., HNCP nodes assume an interface to not be internal, even though it was intended to be.
当使用自动检测时，不遵循此规则（例如，运行未修改的DHCP服务器）可能会导致误报，即HNCP节点假定接口不是内部接口，即使它本来是内部接口。
This section defines the interface classification algorithm. It is suitable for both IPv4 and IPv6 (single or dual stack) and detects the category of an interface either automatically or based on a fixed configuration. By determining the category for all interfaces, the network borders are implicitly defined, i.e., all interfaces not belonging to the External category are considered to be within the borders of the network; all others are not.
本节定义了接口分类算法。它适用于IPv4和IPv6（单堆栈或双堆栈），并自动或基于固定配置检测接口的类别。通过确定所有接口的类别，网络边界被隐式定义，即，不属于外部类别的所有接口被视为在网络边界内；其他的都不是。
The following algorithm MUST be implemented by any node implementing HNCP. However, if the node does not implement auto-detection, only the first and last step are required. The algorithm works as follows, with evaluation stopping at first match:
以下算法必须由实现HNCP的任何节点实现。但是，如果节点未实现自动检测，则只需要第一步和最后一步。该算法的工作原理如下，计算在第一次匹配时停止：
1. If a fixed category is configured for an interface, it is used.
1. 如果为接口配置了固定类别，则使用该类别。
2. If a delegated prefix could be acquired by running a DHCPv6 client, it is considered external. The DHCPv6 client MUST have included a DHCPv6 user class consisting of the ASCII string "HOMENET" in all of its requests.
2. 如果可以通过运行DHCPv6客户机获得委派前缀，则认为它是外部的。DHCPv6客户端必须在其所有请求中包含由ASCII字符串“HOMENET”组成的DHCPv6用户类。
3. If an IPv4 address could be acquired by running a DHCPv4 client on the interface, it is considered external. The DHCPv4 client MUST have included a DHCP user class consisting of the ASCII string "HOMENET" in all of its requests.
3. 如果可以通过在接口上运行DHCPv4客户端来获取IPv4地址，则将其视为外部地址。DHCPv4客户端必须在其所有请求中包含由ASCII字符串“HOMENET”组成的DHCP用户类。
4. The interface is considered internal.
4. 该接口被视为内部接口。
Note that as other HNCP nodes will ignore the client due to the User Class option, any server that replies is clearly external (or a malicious internal node).
请注意，由于用户类选项，其他HNCP节点将忽略客户端，因此任何应答的服务器都显然是外部的（或恶意的内部节点）。
An HNCP router SHOULD allow setting the fixed category for each interface that may be connected to either an internal or external device (e.g., an Ethernet port that can be connected to a modem, another HNCP router, or a client). Note that all fixed categories except internal and external cannot be auto-detected and can only be selected using manual configuration.
HNCP路由器应允许为可能连接到内部或外部设备（例如，可连接到调制解调器、另一个HNCP路由器或客户端的以太网端口）的每个接口设置固定类别。请注意，除内部和外部之外的所有固定类别都无法自动检测，只能使用手动配置进行选择。
An HNCP router using auto-detection on an interface MUST run the appropriately configured DHCP clients as long as the interface without a fixed category is active (including states where auto-detection considers it to be internal) and rerun the algorithm above to react to conditions resulting in a different interface category. The router SHOULD wait for a reasonable time period (5 seconds as a
在接口上使用自动检测的HNCP路由器必须运行适当配置的DHCP客户端，只要没有固定类别的接口处于活动状态（包括自动检测将其视为内部的状态），并重新运行上述算法以对导致不同接口类别的条件作出反应。路由器应等待一段合理的时间（通常为5秒）
default), during which the DHCP clients can acquire a lease, before treating a newly activated or previously external interface as internal.
默认情况下），在此期间，DHCP客户端可以获得租约，然后将新激活的或以前的外部接口视为内部接口。
This section specifies how HNCP nodes configure host and node addresses. At first, border routers share information obtained from service providers or local configuration by publishing one or more External-Connection TLVs (Section 10.2). These contain other TLVs such as Delegated-Prefix TLVs (Section 10.2.1) that are then used for prefix assignment. Finally, HNCP nodes obtain addresses either statelessly or using a specific stateful mechanism (Section 6.4). Hosts and non-HNCP routers are configured using SLAAC, DHCP, or DHCPv6-PD.
本节指定HNCP节点如何配置主机和节点地址。首先，边界路由器通过发布一个或多个外部连接TLV共享从服务提供商或本地配置获得的信息（第10.2节）。这些包含其他TLV，如委托前缀TLV（第10.2.1节），然后用于前缀分配。最后，HNCP节点以无状态或使用特定的有状态机制获取地址（第6.4节）。主机和非HNCP路由器使用SLAAC、DHCP或DHCPv6 PD进行配置。
HNCP uses the concept of Common Link both in autonomic address configuration and naming and service discovery (Section 8). A Common Link refers to the set of interfaces of nodes that see each other's traffic and presumably also the traffic of all hosts that may use the nodes to, e.g., forward traffic. Common Links are used, e.g., to determine where prefixes should be assigned or which peers participate in the election of a DHCP server. The Common Link is computed separately for each local internal interface, and it always contains the local interface. Additionally, if the local interface is not set to the Ad Hoc category (see Section 5.1), it also contains the set of interfaces that are bidirectionally reachable from the given local interface; that is, every remote interface of a remote node meeting all of the following requirements:
HNCP在自主地址配置、命名和服务发现（第8节）中使用公共链路的概念。公共链路指的是一组节点接口，这些节点可以看到彼此的通信量，也可以是可能使用这些节点来转发通信量的所有主机的通信量。公共链接用于确定应在何处分配前缀或哪些对等方参与DHCP服务器的选择。公共链接是为每个本地内部接口单独计算的，它始终包含本地接口。此外，如果本地接口未设置为特殊类别（见第5.1节），则其还包含可从给定本地接口双向访问的接口集；即，满足以下所有要求的远程节点的每个远程接口：
o The local node publishes a Peer TLV with:
o 本地节点发布具有以下内容的对等TLV：
* Peer Node Identifier = remote node's node identifier
* 对等节点标识符=远程节点的节点标识符
* Peer Endpoint Identifier = remote interface's endpoint identifier
* 对等端点标识符=远程接口的端点标识符
* Endpoint Identifier = local interface's endpoint identifier
* 端点标识符=本地接口的端点标识符
o The remote node publishes a Peer TLV with:
o 远程节点发布具有以下功能的对等TLV：
* Peer Node Identifier = local node's node identifier
* 对等节点标识符=本地节点的节点标识符
* Peer Endpoint Identifier = local interface's endpoint identifier
* 对等端点标识符=本地接口的端点标识符
* Endpoint Identifier = remote interface's endpoint identifier
* 端点标识符=远程接口的端点标识符
A node MUST be able to detect whether two of its local internal interfaces are connected, e.g., by detecting an identical remote interface being part of the Common Links of both local interfaces.
节点必须能够检测其两个本地内部接口是否连接，例如，通过检测作为两个本地接口公共链路一部分的相同远程接口。
Each HNCP router MAY obtain external connection information such as address prefixes, DNS server addresses, and DNS search paths from one or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241], or static configuration. Each individual external connection to be shared in the network is represented by one External-Connection TLV (Section 10.2).
每个HNCP路由器可以从一个或多个源（例如DHCPv6 PD[RFC3633]、NETCONF[RFC6241]或静态配置）获取外部连接信息，例如地址前缀、DNS服务器地址和DNS搜索路径。网络中共享的每个单独外部连接由一个外部连接TLV表示（第10.2节）。
Announcements of individual external connections can consist of the following components:
单个外部连接的公告可以由以下组件组成：
Delegated Prefixes: Address space available for assignment to internal links announced using Delegated-Prefix TLVs (Section 10.2.1). Some address spaces might have special properties that are necessary to understand in order to handle them (e.g., information similar to [RFC6603]). This information is encoded using DHCPv6-Data TLVs (Section 10.2.2) inside the respective Delegated-Prefix TLVs.
委派前缀：可分配给使用委派前缀TLV宣布的内部链接的地址空间（第10.2.1节）。某些地址空间可能具有处理它们所需的特殊属性（例如，类似于[RFC6603]的信息）。该信息使用DHCPv6数据TLV（第10.2.2节）在各自的委托前缀TLV内进行编码。
Auxiliary Information: Information about services such as DNS or time synchronization regularly used by hosts in addition to addressing and routing information. This information is encoded using DHCPv6-Data TLVs (Section 10.2.2) and DHCPv4-Data TLVs (Section 10.2.3).
辅助信息：除地址和路由信息外，主机经常使用的DNS或时间同步等服务信息。该信息使用DHCPv6数据TLV（第10.2.2节）和DHCPv4数据TLV（第10.2.3节）进行编码。
Whenever information about reserved parts (e.g., as specified in [RFC6603]) is received for a delegated prefix, the reserved parts MUST be advertised using Assigned-Prefix TLVs (Section 10.3) with the greatest priority (i.e., 15), as if they were assigned to a Private Link.
每当接收到关于保留部件的信息（如[RFC6603]中规定的）作为委托前缀时，必须使用具有最高优先级（即15）的分配前缀TLV（第10.3节）公布保留部件，就好像它们被分配给专用链路一样。
Some connections or delegated prefixes may have a special meaning and are not regularly used for internal or Internet connectivity; instead, they may provide access to special services like VPNs, sensor networks, Voice over IP (VoIP), IPTV, etc. Care must be taken that these prefixes are properly integrated and dealt with in the network, in order to avoid breaking connectivity for devices who are not aware of their special characteristics or to only selectively allow certain devices to use them. Such prefixes are distinguished using Prefix-Policy TLVs (Section 10.2.1.1). Their contents MAY be
某些连接或委托前缀可能具有特殊含义，并且不经常用于内部或互联网连接；相反，它们可以提供对VPN、传感器网络、IP语音（VoIP）、IPTV等特殊服务的访问。必须注意这些前缀在网络中正确集成和处理，为了避免断开不知道其特殊特性的设备的连接，或仅选择性地允许某些设备使用它们。使用前缀策略TLV区分这些前缀（第10.2.1.1节）。其内容可能是
partly opaque to HNCP nodes, and their identification and usage depends on local policy. However, the following general rules MUST be adhered to:
HNCP节点部分不透明，其标识和使用取决于本地策略。但是，必须遵守以下一般规则：
Special rules apply when making address assignments for prefixes with Prefix-Policy TLVs with type 131, as described in Section 6.3.2.
如第6.3.2节所述，为前缀策略为类型为131的TLV的前缀分配地址时，适用特殊规则。
In the presence of any type 1 to 128 Prefix-Policy TLV, the prefix is specialized to reach destinations denoted by any such Prefix-Policy TLV, i.e., in absence of a type 0 Prefix-Policy TLV, it is not usable for general Internet connectivity. An HNCP router MAY enforce this restriction with appropriate packet filter rules.
在存在任何类型1到128前缀策略TLV的情况下，前缀专用于到达由任何此类前缀策略TLV表示的目的地，即，在没有类型0前缀策略TLV的情况下，它不可用于一般因特网连接。HNCP路由器可以使用适当的数据包过滤规则来实施该限制。
HNCP uses the prefix assignment algorithm [RFC7695] in order to assign prefixes to HNCP internal links and uses some of the terminology (Section 2) defined there. HNCP furthermore defines the Assigned-Prefix TLV (Section 10.3), which MUST be used to announce Published Assigned Prefixes.
HNCP使用前缀分配算法[RFC7695]为HNCP内部链接分配前缀，并使用其中定义的一些术语（第2节）。HNCP还定义了分配前缀TLV（第10.3节），必须使用该前缀来公布已发布的分配前缀。
All HNCP nodes running the prefix assignment algorithm use the following values for its parameters:
所有运行前缀分配算法的HNCP节点的参数都使用以下值：
Node IDs: HNCP node identifiers are used. The comparison operation is defined as bitwise comparison.
节点ID：使用HNCP节点标识符。比较操作定义为按位比较。
Set of Delegated Prefixes: The set of prefixes encoded in Delegated-Prefix TLVs that are not strictly included in prefixes encoded in other Delegated-Prefix TLVs. Note that Delegated-Prefix TLVs included in ignored External-Connection TLVs are not considered. It is dynamically updated as Delegated-Prefix TLVs are added or removed.
委托前缀集：在委托前缀TLV中编码的前缀集，不严格包括在其他委托前缀TLV中编码的前缀中。请注意，不考虑忽略的外部连接TLV中包含的委托前缀TLV。它在添加或删除委派前缀TLV时动态更新。
Set of Shared Links: The set of Common Links associated with interfaces with the Internal, Leaf, Guest, or Ad Hoc category. It is dynamically updated as interfaces are added, removed, or switched from one category to another. When multiple interfaces are detected as belonging to the same Common Link, prefix assignment is disabled on all of these interfaces except one.
共享链接集：与内部、叶、来宾或特殊类别的接口关联的公共链接集。随着接口的添加、删除或从一个类别切换到另一个类别，它会动态更新。当检测到多个接口属于同一公共链接时，除一个接口外，所有这些接口上的前缀分配都被禁用。
Set of Private Links: This document defines Private Links as representing DHCPv6-PD clients or as a mean to advertise prefixes included in the DHCPv6 Exclude Prefix option. Other implementation-specific Private Links may be defined whenever a prefix needs to be assigned for a purpose that does not require a consensus with other HNCP nodes.
私有链接集：本文档将私有链接定义为表示DHCPv6 PD客户端或作为播发DHCPv6排除前缀选项中包含的前缀的手段。只要为了不需要与其他HNCP节点达成一致的目的而需要分配前缀，就可以定义其他特定于实现的专用链路。
Set of Advertised Prefixes: The set of prefixes included in Assigned-Prefix TLVs advertised by other HNCP nodes (prefixes advertised by the local node are not in this set). The associated Advertised Prefix Priority is the priority specified in the TLV. The associated Shared Link is determined as follows:
播发前缀集：其他HNCP节点播发的已分配前缀TLV中包含的前缀集（本地节点播发的前缀不在此集中）。关联的播发前缀优先级是TLV中指定的优先级。关联的共享链接的确定如下所示：
* If the Link Identifier is 0, the Advertised Prefix is not assigned on a Shared Link.
* 如果链接标识符为0，则不会在共享链接上分配播发前缀。
* If the other node's interface identified by the Link Identifier is included in one of the Common Links used for prefix assignment, it is considered as assigned on the given Common Link.
* 如果由链路标识符标识的另一个节点的接口包括在用于前缀分配的公共链路之一中，则该接口被视为在给定的公共链路上分配的。
* Otherwise, the Advertised Prefix is not assigned on a Shared Link.
* 否则，不会在共享链接上分配播发的前缀。
Advertised Prefixes as well as their associated priorities and associated Shared Links MUST be updated as Assigned-Prefix TLVs are added, updated, or removed, and as Common Links are modified.
添加、更新或删除分配的前缀TLV以及修改公共链接时，必须更新播发的前缀及其关联的优先级和关联的共享链接。
ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix adoption is done instantly).
采用\最大\延迟：默认值为0秒（即前缀采用立即完成）。
BACKOFF_MAX_DELAY: The default value is 4 seconds.
后退\最大\延迟：默认值为4秒。
RANDOM_SET_SIZE: The default value is 64.
随机设置大小：默认值为64。
Flooding Delay: The default value is 5 seconds.
泛洪延迟：默认值为5秒。
Default Advertised Prefix Priority: When a new assignment is created or an assignment is adopted -- as specified in the prefix assignment algorithm routine -- the default Advertised Prefix Priority to be used is 2.
默认播发前缀优先级：当创建新分配或采用分配时（如前缀分配算法例程中所指定），要使用的默认播发前缀优先级为2。
Whenever the prefix assignment algorithm subroutine (Section 4.1 of [RFC7695]) is run on a Common Link, and whenever a new prefix may be assigned (case 1 of the subroutine: no Best Assignment and no Current Assignment), the decision of whether the assignment of a new prefix is desired MUST follow these rules in order:
每当前缀分配算法子程序（RFC7695第4.1节）在公共链路上运行时，以及每当可以分配新前缀时（子程序的情况1：无最佳分配和无当前分配），是否需要分配新前缀的决定必须遵循以下规则：
If the Delegated-Prefix TLV contains a DHCPv6-Data TLV, and the meaning of one of the DHCP options is not understood by the HNCP node, the creation of a new prefix is not desired. This rule applies to TLVs inside Delegated-Prefix TLVs but not to those inside External-Connection TLVs.
如果委派前缀TLV包含DHCPv6数据TLV，且HNCP节点不理解其中一个DHCP选项的含义，则不需要创建新前缀。此规则适用于委托前缀TLV内的TLV，但不适用于外部连接TLV内的TLV。
If the remaining preferred lifetime of the prefix is 0 and there is another delegated prefix of the same IP version used for prefix assignment with a non-zero preferred lifetime, the creation of a new prefix is not desired.
如果前缀的剩余首选生存期为0，并且有另一个相同IP版本的委派前缀用于具有非零首选生存期的前缀分配，则不需要创建新前缀。
If the Delegated-Prefix TLV does not include a Prefix-Policy TLV indicating restrictive assignment (type 131) or if local policy exists to identify it based on, e.g., other Prefix-Policy TLV values and allows assignment, the creation of a new prefix is desired.
如果委托前缀TLV不包括指示限制性分配的前缀策略TLV（类型131），或者如果存在本地策略以基于（例如）其他前缀策略TLV值来识别它并允许分配，则需要创建新前缀。
Otherwise, the creation of a new prefix is not desired.
否则，不需要创建新前缀。
If the considered delegated prefix is an IPv6 prefix, and whenever there is at least one available prefix of length 64, a prefix of length 64 MUST be selected unless configured otherwise. In case no prefix of length 64 would be available, a longer prefix MAY be selected even without configuration.
如果所考虑的委派前缀是IPv6前缀，并且每当至少有一个长度为64的可用前缀时，除非另有配置，否则必须选择长度为64的前缀。如果没有长度为64的前缀可用，即使没有配置，也可以选择更长的前缀。
If the considered delegated prefix is an IPv4 prefix (Section 6.5 details how IPv4-delegated prefixes are generated), a prefix of length 24 SHOULD be preferred.
如果考虑的委派前缀是IPv4前缀（第6.5节详细介绍了如何生成IPv4委派前缀），则应首选长度为24的前缀。
In any case, an HNCP router making an assignment MUST support a mechanism suitable to distribute addresses from the considered prefix if the link is intended to be used by clients. In this case, a router assigning an IPv4 prefix MUST announce the L-capability, and a router assigning an IPv6 prefix with a length greater than 64 MUST announce the H-capability as defined in Section 4.
在任何情况下，进行分配的HNCP路由器必须支持一种机制，该机制适用于在客户端打算使用链路的情况下从所考虑的前缀分配地址。在这种情况下，分配IPv4前缀的路由器必须宣布L-能力，分配长度大于64的IPv6前缀的路由器必须宣布第4节中定义的H-能力。
The prefix assignment algorithm indicates when a prefix is applied to the respective Common Link. When that happens, each router connected to said link:
前缀分配算法指示何时将前缀应用于相应的公共链路。发生这种情况时，连接到所述链路的每个路由器：
MUST forward traffic destined to said prefix to the respective link.
必须将目的地为所述前缀的流量转发到相应的链路。
MUST participate in the client configuration election as described in Section 7, if the link is intended to be used by clients.
如果链接拟由客户端使用，则必须按照第7节所述参与客户端配置选择。
MAY add an address from said prefix to the respective network interface as described in Section 6.4, e.g., if it is to be used as source for locally originating traffic.
如第6.4节所述，可将所述前缀中的地址添加到相应的网络接口，例如，如果该地址将用作本地发起流量的源。
When an HNCP router announcing the P-Capability (Section 4) receives a DHCPv6-PD request from a client, it SHOULD assign one prefix per delegated prefix in the network. This set of assigned prefixes is then delegated to the client, after it has been applied as described in the prefix assignment algorithm. Each DHCPv6-PD client MUST be considered as an independent Private Link, and delegation MUST be based on the same set of delegated prefixes as the one used for Common Link prefix assignments; however, the prefix length to be delegated MAY be smaller than 64.
当宣布P-Capability（第4节）的HNCP路由器从客户端接收到DHCPv6 PD请求时，它应该为网络中的每个委派前缀分配一个前缀。按照前缀分配算法中的描述应用此前缀集后，将其委托给客户端。每个DHCPv6 PD客户机必须被视为独立的专用链路，并且委托必须基于与用于公共链路前缀分配相同的委托前缀集；但是，要委派的前缀长度可能小于64。
The assigned prefixes MUST NOT be given to DHCPv6-PD clients before they are applied and MUST be withdrawn whenever they are destroyed. As an exception to this rule, in order to shorten delays of processed requests, a router MAY prematurely give out a prefix that is advertised but not yet applied if it does so with a valid lifetime of not more than 30 seconds and ensures removal or correction of lifetimes as soon as possible.
在应用DHCPv6 PD客户端之前，不得将分配的前缀提供给它们，并且在销毁它们时必须将其收回。作为该规则的例外情况，为了缩短已处理请求的延迟，路由器可能会提前发出一个已公布但尚未应用的前缀，前提是其有效生存期不超过30秒，并确保尽快删除或更正生存期。
This section specifies how HNCP nodes reserve addresses for their own use. Nodes MAY, at any time, try to reserve a new address from any Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6 address and -- if it supports IPv4 -- MUST announce an IPv4 address, whenever matching prefixes are assigned to at least one of its Common Links. These addresses are published using Node-Address TLVs and used to locally reach HNCP nodes for other services. Nodes SHOULD NOT create and announce more than one assignment per IP version to avoid cluttering the node data with redundant information unless a special use case requires it.
本节指定HNCP节点如何保留地址供自己使用。节点可以在任何时候尝试从任何应用的分配前缀中保留新地址。每个HNCP节点都应该宣布一个IPv6地址，并且（如果它支持IPv4的话）必须宣布一个IPv4地址，只要匹配的前缀被分配给它的至少一个公共链路。这些地址使用节点地址TLV发布，并用于本地到达HNCP节点以获得其他服务。除非特殊用例需要，否则节点不应为每个IP版本创建和宣布多个分配，以避免节点数据与冗余信息混淆。
Stateless assignment based on Semantically Opaque Interface Identifiers [RFC7217] SHOULD be used for address assignment whenever possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4 if supported) the following method MUST be used instead: For any assigned prefix for which stateless assignment is not used, the first quarter of the addresses are reserved for HNCP-based address assignments, whereas the last three quarters are left to the DHCP elected router (Section 4 specifies the DHCP server election process). For example, if the prefix 192.0.2.0/24 is assigned and applied to a Common Link, addresses included in 192.0.2.0/26 are reserved for HNCP nodes, and the remaining addresses are reserved for the elected DHCPv4 server.
基于语义不透明接口标识符的无状态分配[RFC7217]应尽可能用于地址分配（例如，前缀长度为64），否则（例如，对于IPv4，如果支持），必须使用以下方法：对于未使用无状态分配的任何已分配前缀，第一个四分之一的地址保留用于基于HNCP的地址分配，而最后三个四分之一留给DHCP选择的路由器（第4节规定了DHCP服务器选择过程）。例如，如果将前缀192.0.2.0/24分配并应用于公共链路，则192.0.2.0/26中包含的地址将保留给HNCP节点，其余地址将保留给选定的DHCPv4服务器。
HNCP nodes assign addresses to themselves and then (to ensure eventual lack of conflicting assignments) publish the assignments using the Node-Address TLV (Section 10.4).
HNCP节点将地址分配给自己，然后（为了确保最终没有冲突的分配），使用节点地址TLV发布分配（第10.4节）。
The process of obtaining addresses is specified as follows:
获取地址的过程规定如下：
o A node MUST NOT start advertising an address if it is already advertised by another node.
o 如果地址已由另一个节点播发，则该节点不得开始播发地址。
o An assigned address MUST be part of an assigned prefix currently applied on a Common Link that includes the interface specified by the endpoint identifier.
o 分配的地址必须是当前应用于公共链接（包括端点标识符指定的接口）的分配前缀的一部分。
o An address MUST NOT be used unless it has been advertised for at least ADDRESS_APPLY_DELAY consecutive seconds and is still currently being advertised. The default value for ADDRESS_APPLY_DELAY is 3 seconds.
o 不得使用地址，除非该地址已播发至少连续几秒且当前仍在播发中。地址应用延迟的默认值为3秒。
o Whenever the same address is advertised by more than one node, all but the one advertised by the node with the greatest node identifier MUST be removed.
o 每当同一地址由多个节点播发时，除了由具有最大节点标识符的节点播发的地址外，必须删除所有地址。
HNCP routers can create a Unique Local Address (ULA) or private IPv4 prefix to enable connectivity between local devices. These prefixes are inserted in HNCP as if they were delegated prefixes of a (virtual) external connection (Section 6.2). The following rules apply:
HNCP路由器可以创建唯一本地地址（ULA）或专用IPv4前缀，以实现本地设备之间的连接。这些前缀插入HNCP中，就像它们是（虚拟）外部连接的委派前缀一样（第6.2节）。以下规则适用：
An HNCP router SHOULD create a ULA prefix if there is no other IPv6 prefix with a preferred time greater than 0 in the network. It MAY also do so if there are other delegated IPv6 prefixes, but none of which is locally generated (i.e., without any Prefix-Policy TLV) and has a preferred time greater than 0. However, it
如果网络中没有其他首选时间大于0的IPv6前缀，HNCP路由器应创建ULA前缀。如果存在其他委派的IPv6前缀，但没有一个是本地生成的（即，没有任何前缀策略TLV），并且首选时间大于0，则也可以这样做。但是,
MUST NOT do so otherwise. In case multiple locally generated ULA prefixes are present, only the one published by the node with the greatest node identifier is kept among those with a preferred time greater than 0 -- if there is any.
否则不得这样做。如果存在多个本地生成的ULA前缀，则在首选时间大于0的前缀中，仅保留由具有最大节点标识符的节点发布的前缀（如果有）。
An HNCP router MUST create a private IPv4 prefix [RFC1918] whenever it wishes to provide IPv4 Internet connectivity to the network and no other private IPv4 prefix with Internet connectivity currently exists. It MAY also enable local IPv4 connectivity by creating a private IPv4 prefix if no IPv4 prefix exists but MUST NOT do so otherwise. In case multiple IPv4 prefixes are announced, only the one published by the node with the greatest node identifier is kept among those with a Prefix-Policy TLV of type 0 -- if there is any. The router publishing a prefix with Internet connectivity MUST forward IPv4 traffic to the Internet and perform NAT on behalf of the network as long as it publishes the prefix; other routers in the network MAY choose not to.
每当HNCP路由器希望向网络提供IPv4 Internet连接时，必须创建专用IPv4前缀[RFC1918]，并且当前不存在具有Internet连接的其他专用IPv4前缀。如果不存在IPv4前缀，它还可以通过创建专用IPv4前缀来启用本地IPv4连接，但在其他情况下不能这样做。如果宣布了多个IPv4前缀，则在前缀策略TLV类型为0（如果有）的前缀中，仅保留由具有最大节点标识符的节点发布的前缀。发布具有Internet连接的前缀的路由器必须将IPv4流量转发到Internet，并且只要发布前缀，就必须代表网络执行NAT；网络中的其他路由器可能会选择不这样做。
Creation of such ULA and IPv4 prefixes MUST be delayed by a random time span between 0 and 10 seconds in which the router MUST scan for others trying to do the same.
创建这样的ULA和IPv4前缀必须延迟0到10秒之间的随机时间跨度，路由器必须在该时间跨度内扫描其他试图这样做的人。
When a new ULA prefix is created, the prefix is selected based on the configuration, using the last non-deprecated ULA prefix, or generated based on [RFC4193].
创建新的ULA前缀时，将根据配置选择前缀，使用最后一个未弃用的ULA前缀，或根据[RFC4193]生成前缀。
HNCP routers need to ensure that hosts and non-HNCP downstream routers on internal links are configured with addresses and routes. Since DHCP clients can usually only bind to one server at a time, a per-link and per-service election takes place.
HNCP路由器需要确保内部链路上的主机和非HNCP下游路由器配置有地址和路由。由于DHCP客户端通常一次只能绑定到一台服务器，因此会进行每个链接和每个服务的选择。
HNCP routers may have different capabilities for configuring downstream devices and providing naming services. Each router MUST therefore indicate its capabilities as specified in Section 4 in order to participate as a candidate in the election.
HNCP路由器可能具有配置下游设备和提供命名服务的不同功能。因此，每个路由器必须按照第4节的规定表明其能力，以便作为候选人参加选举。
In general, Stateless Address Autoconfiguration [RFC4861] is used for client configuration for its low overhead and fast renumbering capabilities. Therefore, each HNCP router sends Router Advertisements on interfaces that are intended to be used by clients and MUST at least include a Prefix Information Option for each Applied Assigned Prefix that it assigned to the respective link in every such advertisement. However, stateful DHCPv6 can be used in
通常，无状态地址自动配置[RFC4861]用于客户端配置，因为它具有低开销和快速重新编号功能。因此，每个HNCP路由器在打算由客户端使用的接口上发送路由器广告，并且必须至少包括其在每个这样的广告中分配给相应链路的每个应用分配的前缀的前缀信息选项。但是，有状态DHCPv6可用于
addition by administrative choice to, e.g., collect hostnames and use them to provide naming services or whenever stateless configuration is not applicable.
通过管理选择添加到，例如，收集主机名并使用它们提供命名服务，或者在无状态配置不适用时使用。
The designated stateful DHCPv6 server for a Common Link (Section 6.1) is elected based on the capabilities described in Section 4. The winner is the router (connected to the Common Link) advertising the greatest H-capability. In case of a tie, Capability Values (Section 4) are compared, and the router with the greatest value is elected. In case of another tie, the router with the greatest node identifier is elected among the routers with tied Capability Values.
根据第4节中描述的功能，为公共链路（第6.1节）选择指定的有状态DHCPv6服务器。赢家是路由器（连接到公共链路）广告最大的H-能力。在平局的情况下，比较能力值（第4节），并选择具有最大值的路由器。在另一个tie的情况下，在具有tie能力值的路由器中选择具有最大节点标识符的路由器。
The elected router MUST serve stateful DHCPv6 and SHOULD provide naming services for acquired hostnames as outlined in Section 8; all other nodes MUST NOT. Stateful addresses SHOULD be assigned in a way that does not hinder fast renumbering even if the DHCPv6 server or client do not support the DHCPv6 reconfigure mechanism, e.g., by only handing out leases from locally generated (ULA) prefixes and prefixes with a length different from 64 and by using low renew and rebind times (i.e., not longer than 5 minutes). In case no router was elected, stateful DHCPv6 is not provided. Routers that cease to be elected DHCP servers SHOULD -- when applicable -- invalidate remaining existing bindings in order to trigger client reconfiguration.
所选路由器必须为有状态DHCPv6服务，并应为第8节所述的已获取主机名提供命名服务；所有其他节点都不能。即使DHCPv6服务器或客户端不支持DHCPv6重新配置机制，也应以不妨碍快速重新编号的方式分配有状态地址，例如，仅从本地生成（ULA）前缀和长度不同于64的前缀发出租约，并使用较低的续订和重新绑定时间（即，不超过5分钟）。如果未选择路由器，则不提供有状态DHCPv6。停止选择DHCP服务器的路由器应在适用时使剩余的现有绑定无效，以便触发客户端重新配置。
The designated DHCPv6 server for prefix delegation on a Common Link is elected based on the capabilities described in Section 4. The winner is the router (connected to the Common Link) advertising the greatest P-capability. In case of a tie, Capability Values (Section 4) are compared, and the router with the greatest value is elected. In case of another tie, the router with the greatest node identifier is elected among the routers with tied Capability Values.
根据第4节中描述的功能，选择用于公共链路上前缀委派的指定DHCPv6服务器。赢家是路由器（连接到公共链路）广告最大的P-能力。在平局的情况下，比较能力值（第4节），并选择具有最大值的路由器。在另一个tie的情况下，在具有tie能力值的路由器中选择具有最大节点标识符的路由器。
The elected router MUST provide prefix delegation services [RFC3633] on the given link (and follow the rules in Section 6.3.4); all other nodes MUST NOT.
所选路由器必须在给定链路上提供前缀委派服务[RFC3633]（并遵循第6.3.4节中的规则）；所有其他节点都不能。
The designated DHCPv4 server on a Common Link (Section 6.1) is elected based on the capabilities described in Section 4. The winner is the router (connected to the Common Link) advertising the greatest L-capability. In case of a tie, Capability Values (Section 4) are compared, and the router with the greatest value is elected. In case of another tie, the router with the greatest node identifier is elected among the routers with tied Capability Values.
公共链路（第6.1节）上指定的DHCPv4服务器是根据第4节中描述的功能选择的。赢家是宣传最大L-能力的路由器（连接到公共链路）。在平局的情况下，比较能力值（第4节），并选择具有最大值的路由器。在另一个tie的情况下，在具有tie能力值的路由器中选择具有最大节点标识符的路由器。
The elected router MUST provide DHCPv4 services on the given link; all other nodes MUST NOT. The elected router MUST provide IP addresses from the pool defined in Section 6.4 and MUST announce itself as router [RFC2132] to clients.
所选路由器必须在给定链路上提供DHCPv4服务；所有其他节点都不能。选择的路由器必须提供第6.4节中定义的池中的IP地址，并且必须向客户端宣布自己为路由器[RFC2132]。
DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short (i.e., not longer than 5 minutes) in order to provide reasonable response times to changes. Routers that cease to be elected DHCP servers SHOULD -- when applicable -- invalidate remaining existing bindings in order to trigger client reconfiguration.
DHCPv4的使用寿命-更新和重新绑定时间（T1和T2）应较短（即不超过5分钟），以便对更改提供合理的响应时间。不再被选为DHCP服务器的路由器应该——在适用的情况下——使剩余的现有绑定失效，以便触发客户端重新配置。
The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link is elected based on the capabilities described in Section 4. The winner is the router (connected to the Common Link) advertising the greatest M-capability. In case of a tie, Capability Values (Section 4) are compared, and the router with the greatest value is elected. In case of another tie, the router with the greatest node identifier is elected among the routers with tied Capability Values.
公共链路上的指定多播DNS（MDN）[RFC6762]代理根据第4节中描述的功能进行选择。赢家是宣传最大移动能力的路由器（连接到公共链路）。在平局的情况下，比较能力值（第4节），并选择具有最大值的路由器。在另一个tie的情况下，在具有tie能力值的路由器中选择具有最大节点标识符的路由器。
The elected router MUST provide an mDNS proxy on the given link and announce it as described in Section 8.
选定的路由器必须在给定的链路上提供mDNS代理，并按照第8节中的说明进行宣布。
Network-wide naming and service discovery can greatly improve the user friendliness of a network. The following mechanism provides means to setup and delegate naming and service discovery across multiple HNCP routers.
网络范围的命名和服务发现可以极大地提高网络的用户友好性。以下机制提供了跨多个HNCP路由器设置和委派命名和服务发现的方法。
Each HNCP router SHOULD provide and advertise a recursive name resolving server to clients that honor the announcements made in Delegated-Zone TLVs (Section 10.5), Domain-Name TLVs (Section 10.6), and Node-Name TLVs (Section 10.7), i.e., delegate queries to the designated name servers and hand out appropriate A, AAAA, and PTR records according to the mentioned TLVs.
每个HNCP路由器应向遵守在授权区域TLV（第10.5节）、域名TLV（第10.6节）和节点名TLV（第10.7节）中所做声明的客户端提供并公布递归名称解析服务器，即将查询委托给指定的名称服务器，并分发适当的a、AAAA、，以及根据所述TLV的PTR记录。
Each HNCP router SHOULD provide and announce an auto-generated or user-configured name for each internal Common Link (Section 6.1) for which it is the designated DHCPv4, stateful DHCPv6 server, mDNS proxy, or for which it provides forward or reverse DNS services on behalf of connected devices. This announcement is done using Delegated-Zone TLVs (Section 10.5) and MUST be unique in the whole network. In case of a conflict, the announcement of the node with the greatest node identifier takes precedence, and all other nodes MUST cease to announce the conflicting TLV. HNCP routers providing recursive name resolving services MUST use the included DNS server
每个HNCP路由器应为其指定的DHCPv4、有状态DHCPv6服务器、mDNS代理或代表连接设备提供正向或反向DNS服务的每个内部公共链路（第6.1节）提供并公布自动生成或用户配置的名称。本公告使用授权区域TLV（第10.5节）完成，且必须在整个网络中唯一。在发生冲突的情况下，具有最大节点标识符的节点的公告优先，所有其他节点必须停止公告冲突TLV。提供递归名称解析服务的HNCP路由器必须使用附带的DNS服务器
address within the TLV to resolve names belonging to the zone as if there was an NS record.
TLV内的地址，用于解析属于区域的名称，就像存在NS记录一样。
Each HNCP node SHOULD announce a node name for itself to be easily reachable and MAY announce names on behalf of other devices. Announcements are made using Node-Name TLVs (Section 10.7), and the announced names MUST be unique in the whole network. In case of a conflict, the announcement of the node with the greatest node identifier takes precedence, and all other nodes MUST cease to announce the conflicting TLV. HNCP routers providing recursive name resolving services as described above MUST resolve such announced names to their respective IP addresses as if there were corresponding A/AAAA records.
每个HNCP节点应为其自身宣布一个易于访问的节点名称，并可代表其他设备宣布名称。使用节点名TLV（第10.7节）进行公告，并且公告的名称在整个网络中必须是唯一的。在发生冲突的情况下，具有最大节点标识符的节点的公告优先，所有其他节点必须停止公告冲突TLV。提供如上所述的递归名称解析服务的HNCP路由器必须将这些公布的名称解析为其各自的IP地址，就像存在相应的A/AAAA记录一样。
Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence.
HNCP网络中使用名称和非限定区域，以提供具有本地意义的命名和服务发现。网络范围的区域附加到所有单个标签或不合格区域，以便对其进行限定。默认为“.home”；但是，管理员可以将网络的域名TLV公告（第10.6节）配置为使用不同的域名TLV。如果宣布了多个，则具有最大节点标识符的节点的域优先。
PSKs are often required to secure (for example) IGPs and other protocols that lack support for asymmetric security. The following mechanism manages PSKs using HNCP to enable bootstrapping of such third-party protocols. The scheme SHOULD NOT be used unless it's in conjunction with secured HNCP unicast transport (i.e., DTLS), as transferring the PSK in plaintext anywhere in the network is a potential risk, especially as the originator may not know about security (and use of DNCP security) on all links. The following rules define how such a PSK is managed and used:
通常需要PSK来保护（例如）IGP和其他不支持非对称安全性的协议。以下机制使用HNCP管理PSK，以启用此类第三方协议的引导。除非该方案与安全的HNCP单播传输（即DTL）结合使用，否则不应使用该方案，因为在网络中的任何位置以明文传输PSK是一种潜在风险，特别是因为发起人可能不知道所有链路上的安全性（以及DNCP安全性的使用）。以下规则定义了如何管理和使用此类PSK：
o If no Managed-PSK TLV (Section 10.8) is currently being announced, an HNCP node using this mechanism MUST create one after a random delay of 0 to 10 seconds with a 32 bytes long random key and add it to its node data.
o 如果当前未宣布托管PSK TLV（第10.8节），则使用此机制的HNCP节点必须使用32字节长的随机密钥在0到10秒的随机延迟后创建一个，并将其添加到其节点数据中。
o In case multiple nodes announce such a TLV at the same time, all but the one with the greatest node identifier stop advertising it and adopt the remaining one.
o 如果多个节点同时宣布这样一个TLV，那么除了具有最大节点标识符的节点之外，所有节点都将停止宣传该TLV，并采用剩余的TLV。
o The node currently advertising the Managed-PSK TLV MUST generate and advertise a new random one whenever an unreachable node is removed from the DNCP topology as described in Section 4.6 of [RFC7787].
o 如[RFC7787]第4.6节所述，每当从DNCP拓扑中删除不可访问的节点时，当前播发托管PSK TLV的节点必须生成并播发新的随机节点。
PSKs for individual protocols SHOULD be derived from the random PSK using a suitable one-way hashing algorithm (e.g., by using the HMAC-based Key Derivation Function (HKDF) based on HMAC-SHA256 [RFC6234] with the particular protocol name in the info field) so that disclosure of any derived key does not impact other users of the managed PSK. Furthermore, derived PSKs MUST be updated whenever the managed PSK changes.
应使用合适的单向散列算法（例如，通过使用基于HMAC-SHA256[RFC6234]的基于HMAC的密钥派生函数（HKDF）以及信息字段中的特定协议名称，从随机PSK派生出各个协议的PSK，以便任何派生密钥的披露不会影响受管PSK的其他用户。此外，无论何时托管PSK发生更改，都必须更新派生的PSK。
HNCP defines the following TLVs in addition to those defined by DNCP. The same general rules and defaults for encoding as noted in Section 7 of [RFC7787] apply. Note that most HNCP variable-length TLVs also support optional nested TLVs, and they are encoded after the variable-length content, followed by the zero padding of the variable-length content to the next 32-bit boundary.
除DNCP定义的TLV外，HNCP还定义了以下TLV。[RFC7787]第7节所述的编码一般规则和默认值同样适用。请注意，大多数HNCP可变长度TLV还支持可选的嵌套TLV，它们在可变长度内容之后编码，然后将可变长度内容的零填充到下一个32位边界。
TLVs defined here are only valid when appearing in their designated context, i.e., only directly within container TLVs mentioned in their definition or -- absent any mentions -- only as top-level TLVs within the node data set. TLVs appearing outside their designated context MUST be ignored.
此处定义的TLV仅在其指定上下文中出现时有效，即，仅直接出现在其定义中提到的容器TLV中，或者（未提及）仅作为节点数据集中的顶级TLV出现。必须忽略出现在指定上下文之外的TLV。
TLVs encoding IP addresses or prefixes allow encoding both IPv6 and IPv4 addresses and prefixes. IPv6 information is encoded as is, whereas for IPv4, the IPv4-mapped IPv6 addresses format [RFC4291] is used, and prefix lengths are encoded as the original IPv4 prefix length increased by 96.
TLV编码IP地址或前缀允许同时编码IPv6和IPv4地址和前缀。IPv6信息按原样编码，而对于IPv4，使用IPv4映射IPv6地址格式[RFC4291]，前缀长度按原始IPv4前缀长度增加96的方式编码。
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: HNCP-Version (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
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: HNCP-Version (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
This TLV is used to indicate the supported version and router capabilities of an HNCP node as described in Section 4.
如第4节所述，该TLV用于指示HNCP节点的受支持版本和路由器功能。
Reserved: Bits are reserved for future use. They MUST be set to 0 when creating this TLV, and their value MUST be ignored when processing the TLV.
保留：保留位供将来使用。创建此TLV时必须将其设置为0，处理TLV时必须忽略其值。
M-capability: Priority value used for electing the on-link mDNS [RFC6762] proxy. It MUST be set to 0 if the router is not capable of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use.
M-capability：用于选择链路上MDN[RFC6762]代理的优先级值。如果路由器无法代理MDN，则必须将其设置为0，否则应将其设置为4，但可以将其设置为1到7之间的任何值，以指示非默认优先级。值8-15保留供将来使用。
P-capability: Priority value used for electing the on-link DHCPv6-PD server. It MUST be set to 0 if the router is not capable of providing prefixes through DHCPv6-PD (Section 6.3.4), otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use.
P-capability：用于选择链路上DHCPv6 PD服务器的优先级值。如果路由器无法通过DHCPv6 PD（第6.3.4节）提供前缀，则必须将其设置为0，否则应将其设置为4，但可以将其设置为1到7之间的任何值，以指示非默认优先级。值8-15保留供将来使用。
H-capability: Priority value used for electing the on-link DHCPv6 server offering non-temporary addresses. It MUST be set to 0 if the router is not capable of providing such addresses, otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use.
H-capability：用于选择提供非临时地址的链路上DHCPv6服务器的优先级值。如果路由器不能提供此类地址，则必须将其设置为0，否则应将其设置为4，但可以将其设置为1到7之间的任何值，以指示非默认优先级。值8-15保留供将来使用。
L-capability: Priority value used for electing the on-link DHCPv4 server. It MUST be set to 0 if the router is not capable of running a legacy DHCPv4 server offering IPv4 addresses to clients, otherwise it SHOULD be set to 4 but MAY be set to any value from 1
L-capability：用于选择链路上DHCPv4服务器的优先级值。如果路由器无法运行向客户端提供IPv4地址的旧式DHCPv4服务器，则必须将其设置为0，否则应将其设置为4，但可以将其设置为1中的任何值
to 7 to indicate a non-default priority. The values 8-15 are reserved for future use.
至7表示非默认优先级。值8-15保留供将来使用。
User-Agent: The user-agent is a human-readable UTF-8 string that describes the name and version of the current HNCP implementation.
用户代理：用户代理是一个人类可读的UTF-8字符串，用于描述当前HNCP实现的名称和版本。
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: External-Connection (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
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: External-Connection (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
An External-Connection TLV is a container TLV used to gather network configuration information associated with a single external connection (Section 6.2) to be shared across the HNCP network. A node MAY publish an arbitrary number of instances of this TLV to share the desired number of external connections. Upon reception, the information transmitted in any nested TLVs is used for the purposes of prefix assignment (Section 6.3) and host configuration (Section 7).
外部连接TLV是一个容器TLV，用于收集与单个外部连接（第6.2节）相关的网络配置信息，以便在HNCP网络中共享。节点可以发布此TLV的任意数量的实例，以共享所需数量的外部连接。接收后，在任何嵌套TLV中传输的信息用于前缀分配（第6.3节）和主机配置（第7节）。
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: Delegated-Prefix (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix +
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
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: Delegated-Prefix (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix +
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
The Delegated-Prefix TLV is used by HNCP routers to advertise prefixes that are allocated to the whole network and can be used for prefix assignment. Delegated-Prefix TLVs are only valid inside External-Connection TLVs, and their prefixes MUST NOT overlap with those of other such TLVs in the same container.
HNCP路由器使用委托前缀TLV来公布分配给整个网络的前缀，这些前缀可用于前缀分配。委托前缀TLV仅在外部连接TLV内部有效，其前缀不得与同一容器中其他此类TLV的前缀重叠。
Valid Lifetime Since Origination: The time in seconds the delegated prefix was valid for at the origination time of the node data containing this TLV. The value MUST be updated whenever the node republishes its Node-State TLV.
发起后的有效生存期：在包含此TLV的节点数据发起时，委派前缀有效的时间（秒）。每当节点重新发布其节点状态TLV时，必须更新该值。
Preferred Lifetime Since Origination: The time in seconds the delegated prefix was preferred for at the origination time of the node data containing this TLV. The value MUST be updated whenever the node republishes its Node-State TLV.
自发起以来的首选生存期：在包含此TLV的节点数据发起时，首选委派前缀的时间（秒）。每当节点重新发布其节点状态TLV时，必须更新该值。
Prefix Length: The number of significant bits in the prefix.
前缀长度：前缀中的有效位数。
Prefix: Significant bits of the prefix padded with zeros up to the next byte boundary.
前缀：前缀的有效位，用零填充到下一个字节边界。
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: Prefix-Policy (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type | |
+-+-+-+-+-+-+-+-+ Value +
| |
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: Prefix-Policy (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type | |
+-+-+-+-+-+-+-+-+ Value +
| |
The Prefix-Policy TLV contains information about the policy or applicability of a delegated prefix. This information can be used to determine whether prefixes for a certain use case (e.g., local reachability, Internet connectivity) do exist or are to be acquired and to make decisions about assigning prefixes to certain links or to fine-tune border firewalls. See Section 6.2 for a more in-depth discussion. This TLV is only valid inside a Delegated-Prefix TLV.
前缀策略TLV包含有关委派前缀的策略或适用性的信息。此信息可用于确定特定用例（例如，本地可达性、互联网连接）的前缀是否存在或将被获取，以及决定将前缀分配给特定链接或微调边界防火墙。有关更深入的讨论，请参见第6.2节。此TLV仅在委托前缀TLV内有效。
Policy Type: The type of the policy identifier.
策略类型：策略标识符的类型。
0: Internet connectivity (no value).
0:Internet连接（无值）。
1-128: Explicit destination prefix with the Policy Type being the actual length of the prefix and the value containing significant bits of the destination prefix padded with zeros up to the next byte boundary.
1-128：显式目标前缀，策略类型为前缀的实际长度，值包含目标前缀的有效位，并用零填充到下一个字节边界。
129: DNS domain. The value contains a DNS label sequence encoded per [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label.
129:DNS域。该值包含按照[RFC1035]编码的DNS标签序列。不得使用压缩。标签序列必须以空标签结束。
130: Opaque UTF-8 string (e.g., for administrative purposes).
130：不透明UTF-8字符串（例如，用于管理目的）。
131: Restrictive assignment (no value).
131：限制性赋值（无值）。
132-255: Reserved for future additions.
132-255：保留供将来添加。
Value: A variable-length identifier of the given type.
值：给定类型的可变长度标识符。
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: DHCPv6-Data (37) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 option stream |
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: DHCPv6-Data (37) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 option stream |
This TLV is used to encode auxiliary IPv6 configuration information (e.g., recursive DNS servers) encoded as a stream of DHCPv6 options. It is only valid in an External-Connection TLV or a Delegated-Prefix TLV encoding an IPv6 prefix and MUST NOT occur more than once in any single container. When included in an External-Connection TLV, it contains DHCPv6 options relevant to the external connection as a whole. When included in a delegated prefix, it contains options mandatory to handle said prefix.
此TLV用于编码辅助IPv6配置信息（例如，递归DNS服务器），该信息编码为DHCPv6选项流。它仅在外部连接TLV或对IPv6前缀进行编码的委托前缀TLV中有效，并且在任何单个容器中不得出现多次。当包含在外部连接TLV中时，它包含与整个外部连接相关的DHCPv6选项。当包含在委托前缀中时，它包含处理所述前缀的强制选项。
DHCPv6 option stream: DHCPv6 options encoded as specified in [RFC3315].
DHCPv6选项流：按照[RFC3315]中的规定编码的DHCPv6选项。
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: DHCPv4-Data (38) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv4 option stream |
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: DHCPv4-Data (38) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv4 option stream |
This TLV is used to encode auxiliary IPv4 configuration information (e.g., recursive DNS servers) encoded as a stream of DHCPv4 options. It is only valid in an External-Connection TLV and MUST NOT occur more than once in any single container. It contains DHCPv4 options relevant to the external connection as a whole.
此TLV用于编码作为DHCPv4选项流编码的辅助IPv4配置信息（例如，递归DNS服务器）。它仅在外部连接TLV中有效，并且在任何单个容器中不得出现多次。它包含与整个外部连接相关的DHCPv4选项。
DHCPv4 option stream: DHCPv4 options encoded as specified in [RFC2131].
DHCPv4选项流：按照[RFC2131]中的规定编码的DHCPv4选项。
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: Assigned-Prefix (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
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: Assigned-Prefix (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to announce Published Assigned Prefixes for the purposes of prefix assignment (Section 6.3).
本TLV用于公布已发布的已分配前缀，以便进行前缀分配（第6.3节）。
Endpoint Identifier: The endpoint identifier of the local interface the prefix is assigned to, or 0 if it is assigned to a Private Link (e.g., when the prefix is assigned for downstream prefix delegation).
端点标识符：将前缀分配给的本地接口的端点标识符，如果将前缀分配给专用链接，则为0（例如，当为下游前缀委派分配前缀时）。
Rsv.: Bits are reserved for future use. They MUST be set to 0 when creating this TLV, and their value MUST be ignored when processing the TLV.
Rsv.：保留位供将来使用。创建此TLV时必须将其设置为0，处理TLV时必须忽略其值。
Prty: The Advertised Prefix Priority from 0 to 15.
Prty：播发的前缀优先级从0到15。
0-1: Low priorities.
0-1：低优先级。
2: Default priority.
2：默认优先级。
3-7: High priorities.
3-7：高度优先事项。
8-11: Administrative priorities. MUST NOT be used unless configured otherwise.
8-11：行政优先事项。除非另有配置，否则不得使用。
12-14: Reserved for future use.
12-14：保留供将来使用。
15: Provider priorities. MAY only be used by the router advertising the corresponding delegated prefix and based on static or dynamic configuration (e.g., for excluding a prefix based on the DHCPv6-PD Prefix Exclude Option [RFC6603]).
15：供应商优先事项。只能由公布相应委托前缀的路由器使用，并且基于静态或动态配置（例如，用于排除基于DHCPv6 PD prefix Exclude选项[RFC6603]的前缀）。
Prefix Length: The number of significant bits in the Prefix field.
前缀长度：前缀字段中的有效位数。
Prefix: The significant bits of the prefix padded with zeros up to the next byte boundary.
前缀：前缀的有效位加上零直到下一个字节边界。
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: Node-Address (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
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: Node-Address (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to announce addresses assigned to an HNCP node as described in Section 6.4.
该TLV用于公布分配给HNCP节点的地址，如第6.4节所述。
Endpoint Identifier: The endpoint identifier of the local interface the prefix is assigned to, or 0 if it is not assigned on an HNCP enabled link.
端点标识符：前缀分配给的本地接口的端点标识符，如果未在启用HNCP的链接上分配，则为0。
IP Address: The globally scoped IPv6 address, or the IPv4 address encoded as an IPv4-mapped IPv6 address [RFC4291].
IP地址：全局范围的IPv6地址，或编码为IPv4映射IPv6地址的IPv4地址[RFC4291]。
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: DNS-Delegated-Zone (39) | Length: >= 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved |L|B|S| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
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: DNS-Delegated-Zone (39) | Length: >= 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved |L|B|S| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to announce a forward or reverse DNS zone delegation in the HNCP network. Its meaning is roughly equivalent to specifying an NS and A/AAAA record for said zone. Details are specified in Section 8.
此TLV用于在HNCP网络中宣布正向或反向DNS区域委派。其含义大致相当于为所述区域指定NS和A/AAAA记录。详情见第8节。
IP Address: The IPv6 address of the authoritative DNS server for the zone; IPv4 addresses are represented as IPv4-mapped addresses [RFC4291]. The special value of :: (all zeros) means the delegation is available in the global DNS hierarchy.
IP地址：区域的权威DNS服务器的IPv6地址；IPv4地址表示为IPv4映射地址[RFC4291]。特殊值：：（全零）表示委托在全局DNS层次结构中可用。
Reserved: Those bits MUST be set to 0 when creating the TLV and ignored when parsing it unless defined in a later specification.
保留：除非在以后的规范中定义，否则在创建TLV时必须将这些位设置为0，并在解析TLV时忽略这些位。
L-bit: (DNS-based Service Discovery (DNS-SD) [RFC6763] Legacy-Browse) indicates that this delegated zone SHOULD be included in the network's DNS-SD legacy browse list of domains at lb._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have this bit set; reverse zones SHOULD NOT.
L位：（基于DNS的服务发现（DNS-SD）[RFC6763]旧版浏览）表示此委派区域应包括在lb._DNS-SD._udp.（域名）的网络DNS-SD旧版浏览域列表中。本地正向区应设置此位；反向区域不应出现。
B-bit: (DNS-SD [RFC6763] Browse) indicates that this delegated zone SHOULD be included in the network's DNS-SD browse list of domains at b._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have this bit set; reverse zones SHOULD NOT.
B位：（DNS-SD[RFC6763]浏览）表示此委派区域应包含在网络的DNS-SD浏览列表中，该列表位于B.(DNS-SD.)udp.（域名）。本地正向区应设置此位；反向区域不应出现。
S-bit: (Fully qualified DNS-SD [RFC6763] domain) indicates that this delegated zone consists of a fully qualified DNS-SD domain, which should be used as the base for DNS-SD domain enumeration, i.e., _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set; reverse zones MUST NOT. This can be used to provision a DNS
S位：（完全限定的DNS-SD[RFC6763]域）表示此委派区域由完全限定的DNS-SD域组成，该域应用作DNS-SD域枚举的基础，即_DNS-SD._udp.（区域）存在。正向区域可以设置此位；反向区域不得出现。这可用于设置DNS
search path to hosts for non-local services (such as those provided by an ISP or other manually configured service providers). Zones with this flag SHOULD be added to the search domains advertised to clients.
非本地服务（如ISP或其他手动配置的服务提供商提供的服务）的主机搜索路径。应将具有此标志的区域添加到向客户端播发的搜索域中。
Zone: The label sequence encoded according to [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label.
区域：根据[RFC1035]编码的标签序列。不得使用压缩。标签序列必须以空标签结束。
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: Domain-Name (40) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: Domain-Name (40) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to indicate the base domain name for the network as specified in Section 8. This TLV MUST NOT be announced unless the domain name was explicitly configured by an administrator.
该TLV用于指示第8节中规定的网络的基本域名。除非管理员明确配置了域名，否则不得宣布此TLV。
Domain: The label sequence encoded according to [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label.
域：根据[RFC1035]编码的标签序列。不得使用压缩。标签序列必须以空标签结束。
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: Node-Name (41) | Length: > 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Name |
...
| (not null-terminated, variable length) | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
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: Node-Name (41) | Length: > 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Name |
...
| (not null-terminated, variable length) | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to assign the name of a node in the network to a certain IP address as specified in Section 8.
此TLV用于将网络中节点的名称分配给第8节中指定的特定IP地址。
IP Address: The IP address associated with the name. IPv4 addresses are encoded using IPv4-mapped IPv6 addresses.
IP地址：与名称关联的IP地址。IPv4地址使用IPv4映射的IPv6地址进行编码。
Length: The length of the name (0-63).
长度：名称的长度（0-63）。
Name: The name of the node as a single DNS label.
名称：作为单个DNS标签的节点名称。
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: Managed-PSK (42) | Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| Random 256-bit PSK |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
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: Managed-PSK (42) | Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| Random 256-bit PSK |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to announce a PSK for securing third-party protocols exclusively supporting symmetric cryptography as specified in Section 9.
此TLV用于宣布PSK，以保护第9节中规定的专门支持对称加密的第三方协议。
Each node implementing HNCP is subject to the following requirements:
实施HNCP的每个节点都要遵守以下要求：
o It MUST implement HNCP versioning (Section 4) and interface classification (Section 5).
o 它必须实施HNCP版本控制（第4节）和接口分类（第5节）。
o It MUST implement and run the method for securing third-party protocols (Section 9) whenever it uses the security mechanism of HNCP.
o 每当它使用HNCP的安全机制时，它必须实现并运行保护第三方协议的方法（第9节）。
If the node is acting as a router, then the following requirements apply in addition:
如果节点充当路由器，则还应满足以下要求：
o It MUST support Autonomous Address Configuration (Section 6) and configuration of hosts and non-HNCP routers (Section 7).
o 它必须支持自主地址配置（第6节）以及主机和非HNCP路由器的配置（第7节）。
o It SHOULD implement support for naming and service discovery (Section 8) as defined in this document.
o 它应该实现本文档中定义的命名和服务发现支持（第8节）。
o It MAY be able to provide connectivity to IPv4 devices using DHCPv4.
o 它可能能够使用DHCPv4提供到IPv4设备的连接。
o It SHOULD be able to delegate prefixes to legacy IPv6 routers using DHCPv6-PD (Section 6.3.4).
o 它应该能够使用DHCPv6 PD（第6.3.4节）将前缀委托给旧式IPv6路由器。
o In addition, the normative language of "Basic Requirements for IPv6 Customer Edge Routers" [RFC7084] applies with the following adjustments:
o 此外，“IPv6客户边缘路由器基本要求”[RFC7084]的规范性语言适用于以下调整：
* The generic requirements G-4 and G-5 are relaxed such that any known default router on any interface is sufficient for a router to announce itself as the default router; similarly, only the loss of all such default routers results in self-invalidation.
* 通用要求G-4和G-5被放宽，使得任何接口上的任何已知默认路由器足以使路由器宣布自己为默认路由器；类似地，只有丢失所有此类默认路由器才会导致自失效。
* "WAN-Side Configuration" (Section 4.2) applies to interfaces classified as external.
* “WAN端配置”（第4.2节）适用于分类为外部的接口。
* If the Customer Edge (CE) sends a size hint as indicated in WPD-2, the hint MUST NOT be determined by the number of LAN interfaces of the CE but SHOULD instead be large enough to at least accommodate prefix assignments announced for existing delegated or ULA prefixes, if such prefixes exist and unless explicitly configured otherwise.
* 如果客户边缘（CE）发送WPD-2中所示的大小提示，则提示不得由CE的LAN接口数量决定，而是应足够大，以至少容纳为现有委托前缀或ULA前缀宣布的前缀分配（如果存在此类前缀，除非另有明确配置）。
* The dropping of packets with a destination address belonging to a delegated prefix mandated in WPD-5 MUST NOT be applied to destinations that are part of any prefix announced using an Assigned-Prefix TLV by any HNCP router in the network.
* 目的地地址属于WPD-5中规定的委托前缀的数据包的丢弃不得应用于网络中任何HNCP路由器使用指定前缀TLV宣布的任何前缀的一部分的目的地。
* "LAN-Side Configuration" (Section 4.3) applies to interfaces not classified as external.
* “LAN侧配置”（第4.3节）适用于未分类为外部的接口。
* The requirement L-2 to assign a separate /64 to each LAN interface is replaced by the participation in the prefix assignment mechanism (Section 6.3) for each such interface.
* L-2为每个LAN接口分配单独的/64的要求被参与每个此类接口的前缀分配机制（第6.3节）所取代。
* The requirement L-9 is modified, in that the M flag MUST be set if and only if a router connected to the respective Common Link is advertising a non-zero H-capability. The O flag SHOULD always be set.
* 修改了要求L-9，即当且仅当连接到相应公共链路的路由器正在宣传非零H能力时，必须设置M标志。应始终设置O标志。
* The requirement L-12 to make DHCPv6 options available is adapted, in that Canonical Encoding Rules (CER) SHOULD publish the subset of options using the DHCPv6-Data TLV in an External-Connection TLV. Similarly, it SHOULD do the same for DHCPv4 options in a DHCPv4-Data TLV. DHCPv6 options received inside
* 修改了L-12使DHCPv6选项可用的要求，因为规范编码规则（CER）应在外部连接TLV中使用DHCPv6数据TLV发布选项子集。类似地，对于DHCPv4数据TLV中的DHCPv4选项也应如此。内部接收到DHCPv6选项
an OPTION_IAPREFIX [RFC3633] MUST be published using a DHCPv6-Data TLV inside the respective Delegated-Prefix TLV. HNCP routers SHOULD make relevant DHCPv6 and DHCPv4 options available to clients, i.e., options contained in External-Connection TLVs that also include delegated prefixes from which a subset is assigned to the respective link.
必须使用相应委托前缀TLV内的DHCPv6数据TLV发布选项IAPREFIX[RFC3633]。HNCP路由器应向客户端提供相关的DHCPv6和DHCPv4选项，即外部连接TLV中包含的选项，这些选项还包括将子集分配给相应链路的委派前缀。
* The requirement L-13 to deprecate prefixes is applied to all delegated prefixes in the network from which assignments have been made on the respective interface. Furthermore, the Prefix Information Options indicating deprecation MUST be included in Router Advertisements for the remainder of the prefixes' respective valid lifetime but MAY be omitted after at least 2 hours have passed.
* L-13对弃用前缀的要求适用于网络中的所有委派前缀，从中在相应接口上进行分配。此外，在前缀各自的有效生存期的剩余时间内，指示弃用的前缀信息选项必须包括在路由器广告中，但在至少2小时后可以省略。
HNCP enables self-configuring networks, requiring as little user intervention as possible. However, this zero-configuration goal usually conflicts with security goals and introduces a number of threats.
HNCP支持自配置网络，需要尽可能少的用户干预。然而，这种零配置目标通常与安全目标冲突，并引入了许多威胁。
General security issues for existing home networks are discussed in [RFC7368]. The protocols used to set up addresses and routes in such networks to this day rarely have security enabled within the configuration protocol itself. However, these issues are out of scope for the security of HNCP itself.
[RFC7368]中讨论了现有家庭网络的一般安全问题。迄今为止，用于在此类网络中设置地址和路由的协议很少在配置协议本身中启用安全性。然而，这些问题超出了国家警察自身安全的范围。
HNCP is a DNCP-based state synchronization mechanism carrying information with varying threat potential. For this consideration, the payloads defined in DNCP and this document are reviewed:
HNCP是一种基于DNCP的状态同步机制，承载具有不同威胁潜力的信息。为此，对DNCP和本文件中定义的有效载荷进行了审查：
o Network topology information such as HNCP nodes and their common links.
o 网络拓扑信息，如HNCP节点及其公共链接。
o Address assignment information such as delegated and assigned prefixes for individual links.
o 地址分配信息，例如单个链接的委派和分配前缀。
o Naming and service discovery information such as auto-generated or customized names for individual links and nodes.
o 命名和服务发现信息，如单个链接和节点的自动生成或自定义名称。
As described in Section 5.3, an HNCP node determines the internal or external state on a per-interface basis. A firewall perimeter is set up for the external interfaces, and for internal interfaces, HNCP traffic is allowed, with the exception of the Leaf and Guest subcategories.
如第5.3节所述，HNCP节点根据每个接口确定内部或外部状态。为外部接口设置防火墙周界，对于内部接口，允许HNCP流量，但叶和来宾子类别除外。
Threats concerning automatic interface classification cannot be mitigated by encrypting or authenticating HNCP traffic itself since external routers do not participate in the protocol and often cannot be authenticated by other means. These threats include propagation of forged uplinks in the homenet in order to, e.g., redirect traffic destined to external locations and forged internal status by external routers to, e.g., circumvent the perimeter firewall.
由于外部路由器不参与协议，并且通常无法通过其他方式进行身份验证，因此无法通过加密或验证HNCP流量本身来缓解与自动接口分类相关的威胁。这些威胁包括在家庭网络中传播伪造的上行链路，以便（例如）将目的地为外部位置的流量重定向，以及由外部路由器伪造的内部状态，以（例如）绕过外围防火墙。
It is therefore imperative to either secure individual links on the physical or link layer or preconfigure the adjacent interfaces of HNCP routers to an appropriate fixed category in order to secure the homenet border. Depending on the security of the external link, eavesdropping, man-in-the-middle, and similar attacks on external traffic can still happen between a homenet border router and the ISP; however, these cannot be mitigated from inside the homenet. For example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 messages, but this is very rarely implemented in large or small networks. Further, while PPP can provide secure authentication of both sides of a point-to-point link, it is most often deployed with one-way authentication of the subscriber to the ISP, not the ISP to the subscriber.
因此，必须保护物理层或链路层上的单个链路，或将HNCP路由器的相邻接口预配置为适当的固定类别，以保护homenet边界。根据外部链路的安全性，在homenet边界路由器和ISP之间仍然可能发生窃听、中间人攻击和类似的外部流量攻击；但是，无法从家庭网络内部缓解这些问题。例如，DHCPv4定义了[RFC3118]来验证DHCPv4消息，但在大型或小型网络中很少实现。此外，虽然PPP可以为点到点链路的两侧提供安全认证，但它通常部署为用户对ISP的单向认证，而不是ISP对用户的单向认证。
Once the homenet border has been established, there are several ways to secure HNCP against internal threats like manipulation or eavesdropping by compromised devices on a link that is enabled for HNCP traffic. If left unsecured, attackers may perform arbitrary traffic redirection, eavesdropping, spoofing, or denial-of-service attacks on HNCP services such as address assignment or service discovery, and the protocols are secured using HNCP-derived keys such as routing protocols.
一旦建立了家庭网络边界，就有几种方法可以保护HNCP免受内部威胁，如在启用HNCP流量的链路上被受损设备操纵或窃听。如果不加保护，攻击者可能会对HNCP服务（如地址分配或服务发现）执行任意流量重定向、窃听、欺骗或拒绝服务攻击，并使用HNCP派生密钥（如路由协议）保护协议。
Detailed interface categories like "Leaf" or "Guest" can be used to integrate not fully trusted devices to various degrees into the homenet by not exposing them to HNCP traffic or by using firewall rules to prevent them from reaching homenet-internal resources.
详细的接口类别，如“Leaf”或“Guest”，可用于将不完全受信任的设备在不同程度上集成到homenet中，方法是不将其暴露于HNCP流量，或使用防火墙规则阻止其访问homenet内部资源。
On links where this is not practical and lower layers do not provide adequate protection from attackers, DTLS-based secure unicast transport MUST be used to secure traffic.
在不可行且较低层无法提供足够保护以防攻击者攻击的链路上，必须使用基于DTLS的安全单播传输来保护流量。
IGPs and other protocols are usually run alongside HNCP; therefore, the individual security aspects of the respective protocols must be considered. It can, however, be summarized that many protocols to be run in the home (like IGPs) provide -- to a certain extent -- similar
IGP和其他协议通常与HNCP一起运行；因此，必须考虑各个协议的各个安全方面。然而，可以总结的是，许多在家中运行的协议（如IGP）在一定程度上提供了类似的功能
security mechanisms. Most of these protocols do not support encryption and only support authentication based on Pre-Shared Keys natively. This influences the effectiveness of any encryption-based security mechanism deployed by HNCP as homenet routing information is thus usually not encrypted.
安全机制。大多数协议都不支持加密，只支持基于预共享密钥的本地身份验证。这会影响HNCP部署的任何基于加密的安全机制的有效性，因为homenet路由信息通常不会加密。
IANA has set up a registry for the (decimal values within range 32-511) "HNCP TLV Types" under "Distributed Node Consensus Protocol (DNCP)". The registration procedures is 'RFC Required' [RFC5226]. The initial contents are:
IANA已经为“分布式节点一致性协议（DNCP）”下的“HNCP TLV类型”设置了一个注册表（十进制值在32-511范围内）。注册程序为“需要RFC”[RFC5226]。初步内容如下:
32: HNCP-Version
32:HNCP版本
33: External-Connection
33：外部连接
34: Delegated-Prefix
34：委托前缀
35: Assigned-Prefix
35：指定前缀
36: Node-Address
36：节点地址
37: DHCPv4-Data
37:DHCPv4数据
38: DHCPv6-Data
38:DHCPv6数据
39: DNS-Delegated-Zone
39:DNS委派区域
40: Domain-Name
40：域名
41: Node-Name
41：节点名称
42: Managed-PSK
42：托管PSK
43: Prefix-Policy
43：前缀策略
44-511: Unassigned.
44-511：未分配。
768-1023: Reserved for Private Use. This range is used by HNCP for per-implementation experimentation. How collisions are avoided is outside the scope of this document.
768-1023：保留供私人使用。HNCP使用该范围进行每种实施的试验。如何避免冲突超出了本文档的范围。
IANA has registered the UDP port numbers 8231 (service name: hncp-udp-port, description: HNCP) and 8232 (service name: hncp-dtls-port, description: HNCP over DTLS), as well as an IPv6 link-local multicast address FF02:0:0:0:0:0:0:11 (description: All-Homenet-Nodes).
IANA已注册UDP端口号8231（服务名称：hncp UDP端口，描述：hncp）和8232（服务名称：hncp dtls端口，描述：hncp over dtls），以及IPv6链路本地多播地址FF02:0:0:0:0:0:11（描述：所有Homenet节点）。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC 1321，DOI 10.17487/RFC1321，1992年4月<http://www.rfc-editor.org/info/rfc1321>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 2132，DOI 10.17487/RFC2132，1997年3月<http://www.rfc-editor.org/info/rfc2132>.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B., and J. Privat, "The User Class Option for DHCP", RFC 3004, DOI 10.17487/RFC3004, November 2000, <http://www.rfc-editor.org/info/rfc3004>.
[RFC3004]Stump，G.，Droms，R.，Gu，Y.，Vyaghrapuri，R.，Demirtjis，A.，Beser，B.，和J.Privat，“DHCP的用户类选项”，RFC 3004，DOI 10.17487/RFC3004，2000年11月<http://www.rfc-editor.org/info/rfc3004>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.translate error, please retry
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>.
[RFC6092]Woodyatt，J.，Ed.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，DOI 10.17487/RFC6092，2011年1月<http://www.rfc-editor.org/info/rfc6092>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6206]Levis，P.，Clausen，T.，Hui，J.，Gnawali，O.，和J.Ko，“涓流算法”，RFC 6206，DOI 10.17487/RFC6206，2011年3月<http://www.rfc-editor.org/info/rfc6206>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, <http://www.rfc-editor.org/info/rfc6603>.
[RFC6603]Korhonen，J.，Ed.，Savolainen，T.，Krishnan，S.，和O.Troan，“基于DHCPv6的前缀委托的前缀排除选项”，RFC 6603，DOI 10.17487/RFC6603，2012年5月<http://www.rfc-editor.org/info/rfc6603>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<http://www.rfc-editor.org/info/rfc6763>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年4月<http://www.rfc-editor.org/info/rfc7217>.
[RFC7695] Pfister, P., Paterson, B., and J. Arkko, "Distributed Prefix Assignment Algorithm", RFC 7695, DOI 10.17487/RFC7695, November 2015, <http://www.rfc-editor.org/info/rfc7695>.
[RFC7695]Pfister，P.，Paterson，B.，和J.Arkko，“分布式前缀分配算法”，RFC 7695，DOI 10.17487/RFC7695，2015年11月<http://www.rfc-editor.org/info/rfc7695>.
[RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, <http://www.rfc-editor.org/info/rfc7787>.
[RFC7787]Stenberg，M.和S.Barth，“分布式节点共识协议”，RFC 7787，DOI 10.17487/RFC7787，2016年4月<http://www.rfc-editor.org/info/rfc7787>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, <http://www.rfc-editor.org/info/rfc3118>.
[RFC3118]Droms，R.，Ed.和W.Arbaugh，Ed.，“DHCP消息的身份验证”，RFC 3118，DOI 10.17487/RFC3118，2001年6月<http://www.rfc-editor.org/info/rfc3118>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<http://www.rfc-editor.org/info/rfc6762>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[RFC7084]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，RFC 7084，DOI 10.17487/RFC7084，2013年11月<http://www.rfc-editor.org/info/rfc7084>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, <http://www.rfc-editor.org/info/rfc7368>.
[RFC7368]Chown，T.，Ed.，Arkko，J.，Brandt，A.，Troan，O.，和J.Weil，“IPv6家庭网络架构原则”，RFC 7368，DOI 10.17487/RFC7368，2014年10月<http://www.rfc-editor.org/info/rfc7368>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
Acknowledgments
致谢
Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek, and Thomas Clausen for their contributions to the document.
感谢Ole Troan、Mark Baugher、Mark Townsley、Juliusz Chroboczek和Thomas Clausen对该文件的贡献。
Thanks to Eric Kline for the original border discovery work.
感谢Eric Kline最初的边境发现工作。
Authors' Addresses
作者地址
Markus Stenberg Independent Helsinki 00930 Finland
Markus Stenberg独立赫尔辛基00930芬兰
Email: markus.stenberg@iki.fi
Email: markus.stenberg@iki.fi
Steven Barth Independent Halle 06114 Germany
史蒂文·巴特独立学院哈雷06114德国
Email: cyrus@openwrt.org
Email: cyrus@openwrt.org
Pierre Pfister Cisco Systems Paris France
法国巴黎思科系统公司
Email: pierre.pfister@darou.fr
Email: pierre.pfister@darou.fr