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




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.

これはInternet Standards Trackドキュメントです。

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(Internet Engineering Task Force)の製品です。これは、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


Copyright Notice


Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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トラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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
   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
1. Introduction
1. はじめに

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 このドキュメントで定義されていない、ホームネットノード間で状態を共有する必要があり、急速かつ一定の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]に基づくプロトコルであり、セクション3で定義されたノード間で状態を共有するためのトランスポートおよび同期の詳細を定義するDNCPプロファイルが含まれます。ドキュメントの残りの部分は、上記のサービスの動作、必要なTLVのエンコード方法を定義します(セクション10)、およびHNCPノードの動作に関する追加要件(セクション11)。

1.1. Applicability
1.1. 適用性

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.


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は一定のままですが、1つの例外があります。Delegated-PrefixTLV(セクション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機能(ボーダー検出やネーミングの一部の側面など)は、HNCP管理のネットワークを認識していない既存のDHCPサーバーの影響を受ける可能性があるため、予期しない動作が発生しないように再構成する必要がある場合があります。

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ネットワークの一部にはなりません。

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 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.


2. Terminology
2. 用語

The following terms are used as they are defined in [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 The following terms are used as they are defined in [RFC7787]:


o DNCP profile

o DNCPプロファイル

o Node identifier

o ので いでんちふぃえr

o Link

o リンク

o Interface

o インターフェース

(HNCP) node a device implementing this specification.


(HNCP) router a device implementing this specification, which forwards traffic on behalf of other devices.


Greatest node when comparing the DNCP node identifiers of identifier multiple nodes, the one that has the greatest value in a bitwise comparison.


Border separation point between administrative domains; in this case, between the home network and any other network, i.e., usually an ISP network.


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).


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.

Common Link共通のビューを共有するリンク上のノードのセット。つまり、互いのトラフィックと同じホストのセットを参照します。特に設定されていない限り、推移的な接続が想定されます。

DHCPv4 refers to the Dynamic Host Configuration Protocol [RFC2131] in this document.


DHCPv6 refers to the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] in this document.


DHCP refers to cases that apply to both DHCPv4 and DHCPv6 in this document.


2.1. Requirements Language
2.1. 要件言語

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].


3. DNCP Profile
3. DNCPプロファイル

The DNCP profile for HNCP is defined as follows:


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は、ユニキャストとマルチキャストを使用して、リンクローカルスコープのIPv6上のトランスポートとしてポート8231でUDPデータグラムを使用します(FF02:0:0: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ビットのエンドポイント識別子を割り当てなければなりません(MUST)。値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 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.

o HNCPは不透明な32ビットのノード識別子を使用します(DNCP_NODE_IDENTIFIER_LENGTH = 32)。 HNCPを実装するノードは、ランダムなノード識別子を使用する必要があります(SHOULD)。ノード識別子の衝突がある場合([RFC7787]のセクション4.4のノード状態TLV処理で指定されているように)、ノードはその時点で他のどのノードでも使用されていない新しいランダムノード識別子をすぐに生成して使用する必要があります。現在の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ノードは、DNCPハッシュツリーの構築に使用されるDNCPハッシュ関数H(x)として、MD5メッセージダイジェスト[RFC1321]の先行64ビットを使用する必要があります。

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_KEEPALIVE_INTERVAL):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_MULTIPLIER):1つのキープアライブが失われる可能性があるため、実質的にロスレスのリンクでは2.1が正常に機能します。非可逆リンクで使用する場合は、15などのかなり高い乗数を代わりに使用する必要があります。その場合、実装は、そのリンクのキープアライブ間隔を短くして、完全に失われたノードがタイムアウトするまでのタイムアウト(DNCP_KEEPALIVE_INTERVAL * DNCP_KEEPALIVE_MULTIPLIERに等しい)を確保することもできます。

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データが更新されるとタイマーがリセットされるため、SHOULDは1であり、それ以降の再送信ではパケット損失を処理する必要があります。非推移的な非可逆リンクでも、最終的なエンドポイントごとのキープアライブにより、ステータスの同期が確実に行われます。

* Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: earliest transmissions may occur at Imin / 2.

* Iminは200ミリ秒にする必要がありますが、これよりも低くすることはできません。注:初期の送信はImin / 2で発生する可能性があります。

* Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be lower.

* ImaxはImin [RFC6206]の7倍にする必要がありますが、これより低くすることはできません。

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ユニキャストトラフィックは、セキュリティで保護されていないリンクで交換される場合、DNCPで説明されているように、データグラムトランスポート層セキュリティ(DTLS)[RFC6347]を使用して保護する必要があります。このために、ポート8232のUDPが使用されます。 HNCPセキュリティを実装するノードは、DNCP事前共有キー(PSK)メソッドをサポートする必要があり、PKIベースの信頼方法をサポートする必要があり(SHOULD)、DNCP証明書ベースの信頼コンセンサスメソッドをサポートする場合があります(MAY)。 [RFC7525]は、DTLSを安全に利用する方法に関するガイダンスを提供します。

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を無視する必要があります。

4. HNCP Versioning and Router Capabilities
4. HNCPバージョニングとルーター機能

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.

互換性のあるDNCPプロファイルに基づくHNCPの複数のバージョンがHNCPバージョン間で移行するときに同じネットワークに存在する可能性があり、トラブルシューティングの目的で、実行中のHNCPエージェントのバージョンを特定すると有益な場合があります。したがって、各ノードは、ノードデータで現在サポートされているバージョンを示すHNCPバージョンTLV(セクション10.1)を含めなければならず、タイプが32より大きく、ノードによってパブリッシュされているTLVを(DNCP同期目的を除いて)無視する必要があります。 HNCPバージョンの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を通知するノードは、その機能をアドバタイズしないと見なされるため、それぞれの選択には参加しません。

5. Interface Classification
5. インターフェースの分類
5.1. Interface Categories
5.1. インターフェースのカテゴリー

HNCP specifies the following categories that interfaces can be configured to be in:


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.


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エンドポイントとして動作してはなりません(MUST NOT)。外部インターフェースからの内部リソースへのアクセスは制限されています。つまり、顧客宅内機器(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.


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.


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.


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.


5.2. DHCP-Aided Auto-Detection
5.2. DHCP支援自動検出

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.


5.3. Algorithm for Border Discovery
5.3. 境界検出のアルゴリズム

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:


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).


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.


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 default), during which the DHCP clients can acquire a lease, before treating a newly activated or previously external interface as internal.


6. Autonomous Address Configuration
6. 自律アドレス構成

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ノードがホストとノードのアドレスを構成する方法を指定します。最初に、境界ルーターは、1つ以上の外部接続TLVを公開することにより、サービスプロバイダーまたはローカル構成から取得した情報を共有します(セクション10.2)。これらには、プレフィックス割り当てに使用されるDelegated-Prefix TLV(セクション10.2.1)などの他のTLVが含まれています。最後に、HNCPノードは、ステートレスに、または特定のステートフルメカニズムを使用してアドレスを取得します(セクション6.4)。ホストおよび非HNCPルーターは、SLAAC、DHCP、またはDHCPv6-PDを使用して構成されます。

6.1. Common Link
6.1. 共通リンク

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サーバーの選択に参加するピアを決定するために使用されます。共通リンクは、ローカル内部インターフェイスごとに個別に計算され、常にローカルインターフェイスが含まれます。さらに、ローカルインターフェースがAd Hocカテゴリに設定されていない場合(セクション5.1を参照)、特定のローカルインターフェースから双方向に到達可能なインターフェースのセットも含まれます。つまり、次のすべての要件を満たすリモートノードのすべてのリモートインターフェイス。

o The local node publishes a Peer TLV with:

o ローカルノードは、ピアTLVを次のように公開します。

* Peer Node Identifier = remote node's node identifier

* ぺえr ので いでんちふぃえr = れもて ので’s ので いでんちふぃえr

* 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.


6.2. External Connections
6.2. 外部接続

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ルーターは、アドレスプレフィックス、DNSサーバーアドレス、DNS検索パスなどの外部接続情報を、DHCPv6-PD [RFC3633]、NETCONF [RFC6241]、静的構成などの1つ以上のソースから取得できます(MAY)。ネットワークで共有される個々の外部接続は、1つの外部接続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.

Delegated Prefixes:Delegated-Prefix TLV(セクション10.2.1)を使用してアナウンスされた内部リンクへの割り当てに使用可能なアドレス空間。一部のアドレススペースには、それらを処理するために理解する必要がある特別なプロパティがある場合があります(たとえば、[RFC6603]に類似した情報)。この情報は、それぞれのDelegated-Prefix TLV内のDHCPv6-Data TLV(セクション10.2.2)を使用してエンコードされます。

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-Data TLV(セクション10.2.2)およびDHCPv4-Data 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.


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 Their contents MAY be

一部の接続または委任されたプレフィックスには特別な意味があり、内部またはインターネット接続には通常使用されません。代わりに、VPN、センサーネットワーク、Voice over IP(VoIP)、IPTVなどの特別なサービスへのアクセスを提供する場合があります。接続が切断されないように、これらのプレフィックスが適切に統合されてネットワークで処理されるように注意する必要があります。特別な特性を認識していないデバイス、または特定のデバイスのみがそれらを使用できるようにするデバイス。このようなプレフィックスは、Prefix-Policy 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:


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のPrefix-Policy 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ルーターは、適切なパケットフィルタールールでこの制限を実施してもよい(MAY)。

6.3. Prefix Assignment
6.3. プレフィックス割り当て

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はHNCP内部リンクにプレフィックスを割り当てるためにプレフィックス割り当てアルゴリズム[RFC7695]を使用し、そこで定義されている用語(セクション2)の一部を使用します。 HNCPはさらに、Assigned-Prefix TLV(セクション10.3)を定義します。これは、公開された割り当て済みプレフィックスを通知するために使用する必要があります。

6.3.1. Prefix Assignment Algorithm Parameters
6.3.1. プレフィックス割り当てアルゴリズムパラメータ

All HNCP nodes running the prefix assignment algorithm use the following values for its parameters:


Node IDs: HNCP node identifiers are used. The comparison operation is defined as bitwise comparison.


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.

Delegated Prefixesのセット:他のDelegated-Prefix TLVでエンコードされたプレフィックスに厳密に含まれていない、Delegated-Prefix TLVでエンコードされたプレフィックスのセット。無視された外部接続TLVに含まれるDelegated-Prefix TLVは考慮されないことに注意してください。 Delegated-Prefix 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 Exclude Prefixオプションに含まれるプレフィックスをアドバタイズする手段として定義しています。他の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:


* 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.

* リンク識別子によって識別される他のノードのインターフェースが、プレフィックス割り当てに使用される共通リンクの1つに含まれている場合、それは特定の共通リンクに割り当てられていると見なされます。

* 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.


ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix adoption is done instantly).


BACKOFF_MAX_DELAY: The default value is 4 seconds.


RANDOM_SET_SIZE: The default value is 64.


Flooding Delay: The default value is 5 seconds.


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.


6.3.2. Making New Assignments
6.3.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)がCommon Linkで実行される場合、および新しいプレフィックスが割り当てられる可能性がある場合(サブルーチンのケース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.

Delegated-Prefix TLVにDHCPv6-Data TLVが含まれていて、DHCPオプションの1つの意味がHNCPノードによって理解されていない場合、新しいプレフィックスの作成は望ましくありません。このルールはDelegated-Prefix TLV内のTLVに適用されますが、External-Connection 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.


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.

Delegated-Prefix TLVに制限付きの割り当て(タイプ131)を示すPrefix-Policy TLVが含まれていない場合、または他のPrefix-Policy 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.


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.


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.


6.3.3. Applying Assignments
6.3.3. 割り当ての適用

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.


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.3.4. DHCPv6 Prefix Delegation
6.3.4. DHCPv6プレフィックス委任

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.


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.


6.4. Node Address Assignment
6.4. ノードアドレスの割り当て

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アドレスを通知する必要があり(SHOULD)、IPv4をサポートする場合は、一致するプレフィックスがその共通リンクの少なくとも1つに割り当てられている場合は常に、IPv4アドレスを通知する必要があります。これらのアドレスは、Node-Address 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 is assigned and applied to a Common Link, addresses included in are reserved for HNCP nodes, and the remaining addresses are reserved for the elected DHCPv4 server.

意味論的に不透明なインターフェイス識別子に基づくステートレス割り当て[RFC7217]可能な場合は常にアドレス割り当てに使用する必要があります(たとえば、プレフィックスの長さは64)。ステートレス割り当てが使用されない場合、アドレスの最初の4分の1はHNCPベースのアドレス割り当て用に予約されますが、最後の4分の3はDHCP選定ルーターに任されます(セクション4はDHCPサーバー選定プロセスを指定します)。たとえば、プレフィックス192.0.2.0/24が割り当てられ、共通リンクに適用される場合、 / 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).


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 アドレスが少なくともADDRESS_APPLY_DELAY連続してアドバタイズされ、現在アドバタイズされている場合を除き、アドレスを使用してはなりません(MUST NOT)。 ADDRESS_APPLY_DELAYのデフォルト値は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 同じアドレスが複数のノードによってアドバタイズされる場合は常に、最大のノード識別子を持つノードによってアドバタイズされたものを除くすべてを削除する必要があります。

6.5. Local IPv4 and ULA Prefixes
6.5. ローカルIPv4およびULAプレフィックス

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ルーターは、ローカルデバイス間の接続を可能にするために、Unique Local Address(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 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.

HNCPルーターは、ネットワークに優先時間が0より大きい他のIPv6プレフィックスがない場合、ULAプレフィックスを作成する必要があります(SHOULD)。他に委任されたIPv6プレフィックスが存在する場合でも、そうすることができますが、それらのいずれもローカルで生成されず(つまり、Prefix-Policy TLVがない場合)、0よりも優先時間が優先されます。ローカルで生成された複数の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.


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.


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].


7. Configuration of Hosts and Non-HNCP Routers
7. ホストと非HNCPルーターの構成

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クライアントは通常、一度に1つのサーバーにしかバインドできないため、リンクごとおよびサービスごとの選択が行われます。

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.


7.1. IPv6 Addressing and Configuration
7.1. IPv6のアドレス指定と構成

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 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.


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を提供しなければならず(MUST)、セクション8で概説されているように、取得したホスト名にネーミングサービスを提供する必要があります。他のすべてのノードは、してはなりません。ステートフルアドレスは、DHCPv6サーバーまたはクライアントがDHCPv6再構成メカニズムをサポートしていない場合でも、高速再番号付けを妨げない方法で割り当てられる必要があります。たとえば、ローカルで生成された(ULA)プレフィックスと長さが異なるプレフィックスからリースを配布するだけです。 64および短い更新時間と再バインド時間(つまり、5分以内)を使用する。ルータが選択されなかった場合、ステートフルDHCPv6は提供されません。 DHCPサーバーとして選出されるのをやめたルーターは、クライアントの再構成をトリガーするために、残りの既存のバインディングを無効にする必要があります(該当する場合)。

7.2. DHCPv6 for Prefix Delegation
7.2. プレフィックス委任のためのDHCPv6

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.


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.


7.3. DHCPv4 for Addressing and Configuration
7.3. アドレス指定と構成のためのDHCPv4

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.


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 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サーバーとして選出されるのをやめたルーターは、クライアントの再構成をトリガーするために、残りの既存のバインディングを無効にする必要があります(該当する場合)。

7.4. Multicast DNS Proxy
7.4. マルチキャストDNSプロキシ

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.


The elected router MUST provide an mDNS proxy on the given link and announce it as described in Section 8.


8. Naming and Service Discovery
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.


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.


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 address within the TLV to resolve names belonging to the zone as if there was an NS record.

各HNCPルーターは、指定されたDHCPv4、ステートフルDHCPv6サーバー、mDNSプロキシ、またはフォワードまたはリバースDNSサービスを提供する内部共通リンク(セクション6.1)ごとに、自動生成またはユーザー構成の名前を提供および通知する必要があります(SHOULD)。接続されたデバイスに代わって。このアナウンスはDelegated-Zone TLV(セクション10.5)を使用して行われ、ネットワーク全体で一意である必要があります。競合がある場合、最大のノード識別子を持つノードのアナウンスが優先され、他のすべてのノードは競合するTLVのアナウンスを中止する必要があります。再帰的な名前解決サービスを提供するHNCPルーターは、NSレコードが存在するかのように、ゾーンに属する名前を解決するために、TLVに含まれているDNSサーバーアドレスを使用する必要があります。

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ノードは、それ自体が簡単に到達できるようにノード名を通知する必要があり(SHOULD)、他のデバイスに代わって名前を通知する場合があります(MAY)。アナウンスはノード名TLVを使用して行われ(セクション10.7)、アナウンスされた名前はネットワーク全体で一意である必要があります。競合がある場合、最大のノード識別子を持つノードのアナウンスが優先され、他のすべてのノードは競合するTLVのアナウンスを中止する必要があります。上記の再帰的な名前解決サービスを提供するHNCPルーターは、対応するA / AAAAレコードがあるかのように、そのようなアナウンスされた名前をそれぞれのIPアドレスに解決する必要があります。

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を使用するようにドメイン名TLV(セクション10.6)のアナウンスを構成できます(MAY)。複数がアナウンスされる場合、最大のノード識別子を持つノードのドメインが優先されます。

9. Securing Third-Party Protocols
9. サードパーティプロトコルの保護

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:


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 Managed-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のアドバタイズを停止し、残りの1つを採用します。

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トポロジから削除されるたびに、Managed-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.

個々のプロトコルのPSKは、適切な一方向ハッシュアルゴリズムを使用してランダムPSKから導出する必要があります(たとえば、情報に特定のプロトコル名を含むHMAC-SHA256 [RFC6234]に基づくHMACベースの鍵導出関数(HKDF)を使用することにより)フィールド)派生キーの開示が管理対象PSKの他のユーザーに影響を与えないようにします。さらに、派生したPSKは、管理対象のPSKが変更されるたびに更新する必要があります。

10. Type-Length-Value Objects
10. Type-Length-Valueオブジェクト

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.

HNCPは、DNCPによって定義されたものに加えて、次の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.


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.

IPアドレスまたはプレフィックスをエンコードするTLVでは、IPv6とIPv4の両方のアドレスとプレフィックスをエンコードできます。 IPv6情報はそのままエンコードされますが、IPv4の場合、IPv4にマッピングされたIPv6アドレス形式[RFC4291]が使用され、プレフィックス長は、元のIPv4プレフィックス長が96増加したときにエンコードされます。

10.1. HNCP-Version TLV
10.1. HNCPバージョンTLV
    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.


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.


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:リンク上のmDNS [RFC6762]プロキシを選択するために使用される優先度の値。ルータがmDNSのプロキシに対応していない場合は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.


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.


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


to 7 to indicate a non-default priority. The values 8-15 are reserved for future use.


User-Agent: The user-agent is a human-readable UTF-8 string that describes the name and version of the current HNCP implementation.


10.2. External-Connection TLV
10.2. 外部接続TLV
    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).


10.2.1. Delegated-Prefix TLV
10.2.1. 委任プレフィックスTLV
    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.

Delegated-Prefix TLVは、ネットワーク全体に割り当てられ、プレフィックス割り当てに使用できるプレフィックスをアドバタイズするためにHNCPルーターによって使用されます。 Delegated-Prefix TLVはExternal-Connection 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.


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.


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.

プレフィックス:次のバイト境界までゼロが埋め込まれたプレフィックスの有効ビット。 Prefix-Policy TLV プレフィックスポリシーTLV
    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.

Prefix-Policy TLVには、委任されたプレフィックスのポリシーまたは適用性に関する情報が含まれています。この情報を使用して、特定のユースケース(ローカル到達可能性、インターネット接続など)のプレフィックスが存在するか取得するかを決定し、プレフィックスを特定のリンクに割り当てるか、境界ファイアウォールを微調整するかを決定できます。詳細については、セクション6.2を参照してください。このTLVは、Delegated-Prefix TLV内でのみ有効です。

Policy Type: The type of the policy identifier.


0: Internet connectivity (no value).


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.


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.


130: Opaque UTF-8 string (e.g., for administrative purposes).


131: Restrictive assignment (no value).


132-255: Reserved for future additions.


Value: A variable-length identifier of the given type.


10.2.2. DHCPv6-Data TLV
10.2.2. DHCPv6-Data TLV
    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は、DHCPv6オプションのストリームとしてエンコードされた補助IPv6構成情報(再帰DNSサーバーなど)をエンコードするために使用されます。これは、IPv6プレフィックスをエンコードするExternal-Connection TLVまたはDelegated-Prefix TLVでのみ有効であり、単一のコンテナで複数回発生してはなりません。外部接続TLVに含まれる場合、全体として外部接続に関連するDHCPv6オプションが含まれます。委任されたプレフィックスに含まれる場合、プレフィックスを処理するために必須のオプションが含まれます。

DHCPv6 option stream: DHCPv6 options encoded as specified in [RFC3315].


10.2.3. DHCPv4-Data TLV
10.2.3. DHCPv4データTLV
    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サーバーなど)をエンコードするために使用されます。これはExternal-Connection TLVでのみ有効であり、単一のコンテナで複数回発生してはなりません。全体として、外部接続に関連するDHCPv4オプションが含まれています。

DHCPv4 option stream: DHCPv4 options encoded as specified in [RFC2131].


10.3. Assigned-Prefix TLV
10.3. 割り当てられたプレフィックスTLV
    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).


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).


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.


0-1: Low priorities.


2: Default priority.


3-7: High priorities.


8-11: Administrative priorities. MUST NOT be used unless configured otherwise.


12-14: Reserved for future use.


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]).


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.


10.4. Node-Address TLV
10.4. ノードアドレスTLV
    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.


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.


IP Address: The globally scoped IPv6 address, or the IPv4 address encoded as an IPv4-mapped IPv6 address [RFC4291].


10.5. DNS-Delegated-Zone TLV
10.5. DNS委任ゾーンTLV
    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.


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] Legacy-Browse)は、この委任されたゾーンが、lb._dns-sd._udpのドメインのネットワークのDNS-SDレガシー参照リストに含まれる必要があることを示します。 (ドメイン名)。ローカル転送ゾーンはこのビットを設定する必要があります(SHOULD)。逆ゾーンはすべきではありません。

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]参照)は、この委任されたゾーンがb._dns-sd._udp。(DOMAIN-NAME)にあるドメインのネットワークのDNS-SD参照リストに含まれる必要があることを示します。ローカル転送ゾーンはこのビットを設定する必要があります(SHOULD)。逆ゾーンはすべきではありません。

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 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.

Sビット:(完全修飾DNS-SD [RFC6763]ドメイン)は、この委任ゾーンが完全修飾DNS-SDドメインで構成されていることを示します。これは、DNS-SDドメイン列挙のベースとして使用する必要があります(つまり、_dns-sd)。 _udp。(ゾーン)が存在します。フォワードゾーンでこのビットが設定されている場合があります。逆ゾーンはいけません。これは、非ローカルサービス(ISPまたは他の手動で構成されたサービスプロバイダーによって提供されるサービスなど)のホストへのDNS検索パスをプロビジョニングするために使用できます。このフラグを持つゾーンは、クライアントにアドバタイズされる検索ドメインに追加する必要があります(SHOULD)。

Zone: The label sequence encoded according to [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label.


10.6. Domain-Name TLV
10.6. ドメイン名TLV
    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.


Domain: The label sequence encoded according to [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label.


10.7. Node-Name TLV
10.7. ノード名TLV
    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.


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).


Name: The name of the node as a single DNS label.


10.8. Managed-PSK TLV
10.8. マネージドPSK TLV
    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.


11. General Requirements for HNCP Nodes
11. HNCPノードの一般的な要件

Each node implementing HNCP is subject to the following requirements:


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)のサポートを実装する必要があります(SHOULD)。

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を使用してレガシーIPv6ルーターにプレフィックスを委任できる必要があります(セクション6.3.4)。

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.

* Customer Edge(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.

* 各LANインターフェイスに個別の/ 64を割り当てるという要件L-2は、そのような各インターフェイスのプレフィックス割り当てメカニズム(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が変更されました。Mフラグは、それぞれの共通リンクに接続されているルーターがゼロ以外のH機能をアドバタイズしている場合にのみ設定する必要があるという点です。 Oフラグは常に設定する必要があります(SHOULD)。

* 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 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.

* DHCPv6オプションを使用可能にするためのL-12の要件は、Canonical Encoding Rules(CER)が外部接続TLVのDHCPv6-Data TLVを使用してオプションのサブセットを公開する必要があるという点で適合しています。同様に、DHCPv4-Data TLVのDHCPv4オプションについても同じようにする必要があります。 OPTION_IAPREFIX [RFC3633]内で受信したDHCPv6オプションは、それぞれのDelegated-Prefix TLV内のDHCPv6-Data TLVを使用して公開する必要があります。 HNCPルーターは、関連するDHCPv6およびDHCPv4オプションをクライアントが利用できるようにする必要があります(SHOULD)。つまり、サブセットがそれぞれのリンクに割り当てられる委任されたプレフィックスも含む外部接続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時間経過すると省略できます。

12. Security Considerations
12. セキュリティに関する考慮事項

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.


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.


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:


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 個々のリンクとノードの自動生成された名前やカスタマイズされた名前などの名前付けとサービス検出情報。

12.1. Interface Classification
12.1. インターフェースの分類

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.


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.


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.


12.2. Security of Unicast Traffic
12.2. ユニキャストトラフィックのセキュリティ

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.


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.


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.


12.3. Other Protocols in the Home
12.3. 家庭内の他のプロトコル

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 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.


13. IANA Considerations
13. IANAに関する考慮事項

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の10進数値)のレジストリを設定しました。登録手順は「RFCが必要」[RFC5226]です。初期の内容は次のとおりです。

32: HNCP-Version


33: External-Connection


34: Delegated-Prefix


35: Assigned-Prefix


36: Node-Address


37: DHCPv4-Data


38: DHCPv6-Data


39: DNS-Delegated-Zone


40: Domain-Name


41: Node-Name

41: のでーなめ

42: Managed-PSK


43: Prefix-Policy


44-511: Unassigned.


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.


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-port、説明:HNCP)および8232(サービス名:hncp-dtls-port、説明:HNCP over DTLS)、およびIPv6リンクローカルマルチキャストを登録しましたアドレスFF02:0:0:0:0:0:0:11(説明:All-Homenet-Nodes)。

14. References
14. 参考文献
14.1. Normative References
14.1. 引用文献

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <>.

[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、< rfc2119>。

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <>.

[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<>。

[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <>.

[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<>。

[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, <>.

[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、2000年11月、<>。

[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, <>.

[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、2003年7月、<>。

[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, <>.

[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, <>.

[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<>。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <>.

[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<>。

[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, <>.

[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6(IPv6)」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http:/ />。

[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, <>.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、< / 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, <>.

[RFC6092] Woodyatt、J.、Ed。、 "Recommended Simple Security Capability in Customer Premises Equipment(CPE)for Providing Residential IPv6 Internet Service"、RFC 6092、DOI 10.17487 / RFC6092、January 2011、<http://www.rfc>。

[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <>.

[RFC6206] Levis、P.、Clauseen、T.、Hui、J.、Gnawali、O。、およびJ. Ko、「The Trickle Algorithm」、RFC 6206、DOI 10.17487 / RFC6206、2011年3月、<http://>。

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <>.

[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<>。

[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, <>.

[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、<>。

[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <>.

[RFC6763] Cheshire、S。およびM. Krochmal、「DNS-Based Service Discovery」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<>。

[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, <>.

[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成(SLAAC)を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、< / info / rfc7217>。

[RFC7695] Pfister, P., Paterson, B., and J. Arkko, "Distributed Prefix Assignment Algorithm", RFC 7695, DOI 10.17487/RFC7695, November 2015, <>.

[RFC7695] Pfister、P.、Paterson、B。、およびJ. Arkko、「分散プレフィックス割り当てアルゴリズム」、RFC 7695、DOI 10.17487 / RFC7695、2015年11月、< / rfc7695>。

[RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, <>.

[RFC7787] Stenberg、M。、およびS. Barth、「Distributed Node Consensus Protocol」、RFC 7787、DOI 10.17487 / RFC7787、2016年4月、<>。

14.2. Informative References
14.2. 参考引用

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <>.

[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<>。

[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, <>.

[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<>。

[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, <>.

[RFC3118] Droms、R.、Ed。 W. Arbaugh編、「DHCPメッセージの認証」、RFC 3118、DOI 10.17487 / RFC3118、2001年6月、<>。

[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, <>.

[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms(SHA and SHA-based HMAC and HKDF)」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<http://www.rfc->。

[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, <>.

[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol(NETCONF)」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<>。

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <>.

[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<>。

[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, <>.

[RFC7084] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルータの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<http:// www / 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, <>.

[RFC7368] Chown、T.、Ed。、Arkko、J.、Brandt、A.、Troan、O。、およびJ. Weil、「IPv6 Home Networking Architecture Principles」、RFC 7368、DOI 10.17487 / RFC7368、2014年10月、 <>。

[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, <>.

[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security(TLS)およびDatagram Transport Layer Security(DTLS)の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<>。



Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek, and Thomas Clausen for their contributions to the document.

ドキュメントへの貢献に対して、Ole Troan、Mark Ba​​ugher、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フィンランド


Steven Barth Independent Halle 06114 Germany



Pierre Pfister Cisco Systems Paris France

Pierre Pfister Cisco Systems Paris France