[要約] RFC 7788は、ホームネットワーキング制御プロトコルに関する標準化文書であり、ホームネットワークデバイスの制御と管理を目的としています。このプロトコルは、ホームネットワークの効率的な運用とセキュリティの向上を支援します。
Internet Engineering Task Force (IETF) M. Stenberg Request for Comments: 7788 S. Barth Category: Standards Track Independent ISSN: 2070-1721 P. Pfister Cisco Systems April 2016
Home Networking Control Protocol
ホームネットワーク制御プロトコル
Abstract
概要
This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.
このドキュメントでは、ホームネットワークコントロールプロトコル(HNCP)、拡張可能な構成プロトコル、およびホームネットワークデバイスの一連の要件について説明します。 HNCPは、分散ノードコンセンサスプロトコル(DNCP)のプロファイルおよび拡張として説明されています。 HNCPにより、ネットワーク境界の検出、アドレスの自動構成、名前解決、サービス検出、および送信元アドレスと宛先アドレスの両方に基づくルーティングをサポートするルーティングプロトコルの使用が可能になります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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 http://www.rfc-editor.org/info/rfc7788.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7788で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、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
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)。
While HNCP does not deal with routing protocols directly (except potentially informing them about internal and external interfaces if classification specified in Section 5.3 is used), in homenet environments where multiple IPv6 source prefixes can be present, routing based on the source and destination address is necessary [RFC7368]. Ideally, the routing protocol is also zero configuration (e.g., no need to configure identifiers or metrics), although HNCP can also be used with a manually configured routing protocol.
HNCPはルーティングプロトコルを直接処理しませんが(セクション5.3で指定された分類が使用されている場合に内部および外部インターフェースについて通知する可能性がある場合を除いて)、複数のIPv6送信元プレフィックスが存在できるホームネット環境では、送信元および宛先アドレスに基づくルーティングは必要[RFC7368]。理想的には、ルーティングプロトコルもゼロ構成です(たとえば、識別子やメトリックを構成する必要はありません)。ただし、手動で構成されたルーティングプロトコルでHNCPを使用することもできます。
As HNCP uses DNCP as the actual state synchronization protocol, the applicability statement of DNCP applies here as well; HNCP should not be used for any data that changes rapidly and constantly. If such data needs to be published in an HNCP network, 1) a more applicable protocol should be used for those portions, and 2) locators to a server of said protocol should be announced using HNCP instead. An example for this is naming and service discovery (Section 8) for which HNCP only transports DNS server addresses and no actual per-name or per-service data of hosts.
HNCPはDNCPを実際の状態同期プロトコルとして使用するため、DNCPの適用性に関するステートメントがここでも適用されます。 HNCPは、急速に絶えず変化するデータには使用しないでください。そのようなデータをHNCPネットワークで公開する必要がある場合、1)それらの部分にはより適切なプロトコルを使用する必要があり、2)上記のプロトコルのサーバーへのロケーターは、代わりにHNCPを使用して通知する必要があります。この例としては、ネーミングとサービスディスカバリ(セクション8)があり、HNCPはDNSサーバーアドレスのみを転送し、ホストの名前ごとまたはサービスごとの実際のデータは転送しません。
HNCP TLVs specified within this document, in steady state, stay constant, with one exception: as Delegated-Prefix TLVs (Section 10.2.1) do contain lifetimes, they force republishing of that data every time the valid or preferred lifetimes of prefixes are updated (significantly). Therefore, it is desirable for ISPs to provide large enough valid and preferred lifetimes to avoid unnecessary HNCP state churn in homes, but even given non-cooperating ISPs, the state churn is proportional only to the number of externally received delegated prefixes and not to the home network size, and it should therefore be relatively low.
このドキュメントで指定されている定常状態のHNCP TLVは一定のままですが、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は(ホーム)ルーターで使用するように設計されていますが、独自のアドレス割り当てやルーティングなどを実行したい高度なホストでも使用できます。
HNCP is link-layer agnostic; if a link supports IPv6 (link-local) multicast and unicast, HNCP will work on it. Trickle retransmissions and keep-alives will handle both packet loss and non-transitive connectivity, ensuring eventual convergence.
HNCPはリンク層に依存しません。リンクがIPv6(リンクローカル)マルチキャストおよびユニキャストをサポートしている場合、HNCPはそのリンクで動作します。トリクル再送信とキープアライブは、パケット損失と非推移的接続の両方を処理し、最終的な収束を保証します。
The following terms are used as they are defined in [RFC7695]:
次の用語は、[RFC7695]で定義されているとおりに使用されます。
o Advertised Prefix Priority
o アドバタイズされたプレフィックスの優先度
o Advertised Prefix
o アドバタイズされたプレフィックス
o Assigned Prefix
o 割り当てられたプレフィックス
o Delegated Prefix
o 委任されたプレフィックス
o Prefix Adoption
o 接頭辞の採用
o Private Link
o プライベートリンク
o Published Assigned Prefix
o 割り当てられたプレフィックスの公開
o Applied Assigned Prefix
o 適用された割り当て済みプレフィックス
o Shared Link The following terms are used as they are defined in [RFC7787]:
o共有リンク次の用語は、[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)ノードは、この仕様を実装するデバイスです。
(HNCP) router a device implementing this specification, which forwards traffic on behalf of other devices.
(HNCP)他のデバイスに代わってトラフィックを転送する、この仕様を実装するデバイス。
Greatest node when comparing the DNCP node identifiers of identifier multiple nodes, the one that has the greatest value in a bitwise comparison.
識別子の複数のノードのDNCPノード識別子を比較するときの最大のノード。ビットごとの比較で最大の値を持つノード。
Border separation point between administrative domains; in this case, between the home network and any other network, i.e., usually an ISP network.
管理ドメイン間の境界分離ポイント。この場合、ホームネットワークと他のネットワーク間、つまり通常はISPネットワーク間。
Internal link a link that does not cross borders.
内部リンク国境を越えないリンク。
Internal an interface that is connected to an internal link. interface
内部内部リンクに接続されているインターフェース。インターフェース
External an interface that is connected to a link that is interface not an internal link.
外部リンクは、内部リンクではなくインターフェースであるリンクに接続されています。
Interface a local configuration denoting the use of a category particular interface. The Interface category determines how an HNCP node should treat the particular interface. The External and Internal categories mark the interface as out of or within the network border; there are also a number of subcategories of Internal that further affect local node behavior. See Section 5.1 for a list of interface categories and how they behave. The Internal or External category may also be auto-detected (Section 5.3).
カテゴリ固有のインターフェースの使用を示すローカル構成をインターフェースします。インターフェース・カテゴリーは、HNCPノードが特定のインターフェースをどのように処理するかを決定します。外部および内部カテゴリは、インターフェイスをネットワーク境界外またはネットワーク境界内としてマークします。ローカルノードの動作にさらに影響を与える内部のサブカテゴリもいくつかあります。インターフェイスのカテゴリのリストとそれらの動作については、セクション5.1を参照してください。内部または外部カテゴリも自動検出される場合があります(セクション5.3)。
Border router a router announcing external connectivity and forwarding traffic across the network border.
ボーダールーター外部接続をアナウンスし、ネットワークボーダーを介してトラフィックを転送するルーター。
Common Link a set of nodes on a link that share a common view of it, i.e., they see each other's traffic and the same set of hosts. Unless configured otherwise, transitive connectivity is assumed.
Common Link共通のビューを共有するリンク上のノードのセット。つまり、互いのトラフィックと同じホストのセットを参照します。特に設定されていない限り、推移的な接続が想定されます。
DHCPv4 refers to the Dynamic Host Configuration Protocol [RFC2131] in this document.
DHCPv4は、このドキュメントの動的ホスト構成プロトコル[RFC2131]を指します。
DHCPv6 refers to the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] in this document.
DHCPv6は、このドキュメントのIPv6の動的ホスト構成プロトコル(DHCPv6)[RFC3315]を指します。
DHCP refers to cases that apply to both DHCPv4 and DHCPv6 in this document.
DHCPは、このドキュメントのDHCPv4とDHCPv6の両方に該当するケースを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
The DNCP profile for HNCP is defined as follows:
HNCPのDNCPプロファイルは次のように定義されます。
o HNCP uses UDP datagrams on port 8231 as a transport over link-local scoped IPv6, using unicast and multicast (FF02:0:0:0:0:0:0:11 is the HNCP group address). Received datagrams where either or both of the IPv6 source or destination addresses are not link-local scoped MUST be ignored. Replies to multicast and unicast messages MUST be sent to the IPv6 source address and port of the original message. Each node MUST be able to receive (and potentially reassemble) UDP datagrams with a payload of at least 4000 bytes.
o HNCPは、ユニキャストとマルチキャストを使用して、リンクローカルスコープの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を無視する必要があります。
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を通知するノードは、その機能をアドバタイズしないと見なされるため、それぞれの選択には参加しません。
HNCP specifies the following categories that interfaces can be configured to be in:
HNCPは、インターフェースを構成できる以下のカテゴリーを指定します。
Internal category: This declares an interface to be internal, i.e., within the borders of the HNCP network. The interface MUST operate as a DNCP endpoint. Routers MUST forward traffic with appropriate source addresses between their internal interfaces and allow internal traffic to reach external networks. All nodes MUST implement this category, and nodes not implementing any other category implicitly use it as a fixed default.
内部カテゴリ:これは、インターフェイスが内部、つまりHNCPネットワークの境界内であることを宣言します。インターフェイスはDNCPエンドポイントとして動作する必要があります。ルーターは、内部インターフェイス間で適切な送信元アドレスを使用してトラフィックを転送し、内部トラフィックが外部ネットワークに到達できるようにする必要があります。すべてのノードはこのカテゴリを実装する必要があり、他のカテゴリを実装しないノードは暗黙的にそれを固定デフォルトとして使用します。
External category: This declares an interface to be external, i.e., not within the borders of the HNCP network. The interface MUST NOT operate as a DNCP endpoint. Accessing internal resources from external interfaces is restricted, i.e., the use of Recommended Simple Security Capabilities in Customer Premises Equipments (CPEs) [RFC6092] is RECOMMENDED. HNCP routers SHOULD announce acquired configuration information for use in the network as described in Section 6.2, if the interface appears to be connected to an external network. HNCP routers MUST implement this category.
外部カテゴリ:これは、外部、つまりHNCPネットワークの境界内にないインターフェースを宣言します。インターフェイスはDNCPエンドポイントとして動作してはなりません(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.
リーフカテゴリ:クライアントデバイスのみが使用するインターフェースを宣言します。このようなインターフェイスは、DNCPエンドポイントとして動作してはならないことを除いて、内部カテゴリを使用します。このカテゴリはHNCPルーターでサポートされるべきです(SHOULD)。
Guest category: This declares an interface used by untrusted client devices only. In addition to the restrictions of the Leaf category, HNCP routers MUST filter traffic from and to the interface such that connected devices are unable to reach other devices inside the HNCP network or query services advertised by them unless explicitly allowed. This category SHOULD be supported by HNCP routers.
ゲストカテゴリ:信頼されていないクライアントデバイスのみが使用するインターフェイスを宣言します。リーフカテゴリの制限に加えて、明示的に許可されていない限り、接続されたデバイスがHNCPネットワーク内の他のデバイスに到達したり、アドバタイズされたサービスに問い合わせたりできないように、インターフェイスからのトラフィックをHNCPルーターはフィルタリングする必要があります。このカテゴリはHNCPルーターでサポートされるべきです(SHOULD)。
Ad Hoc category: This configures an interface to use the Internal category, but no assumption is made about the link's transitivity. All other interface categories assume transitive connectivity. This affects the Common Link (Section 6.1) definition. Support for this category is OPTIONAL.
アドホックカテゴリ:これは、内部カテゴリを使用するようにインターフェイスを構成しますが、リンクの推移性については想定されていません。他のすべてのインターフェイスカテゴリは、推移的な接続を前提としています。これは、共通リンク(セクション6.1)の定義に影響します。このカテゴリのサポートはオプションです。
Hybrid category: This declares an interface to use the Internal category while still trying to acquire (external) configuration information on it, e.g., by running DHCP clients. This is useful, e.g., if the link is shared with a non-HNCP router under control and still within the borders of the same network. Detection of this category automatically in addition to manual configuration is out of scope of this document. Support for this category is OPTIONAL.
ハイブリッドカテゴリ:これは、たとえばDHCPクライアントを実行するなどして、(外部)構成情報を取得しようとしながら、内部カテゴリを使用するようにインターフェイスを宣言します。これは、たとえば、リンクが制御下にあり、同じネットワークの境界内にある非HNCPルーターと共有されている場合に便利です。手動構成に加えて、このカテゴリーを自動的に検出することは、このドキュメントの範囲外です。このカテゴリのサポートはオプションです。
Auto-detection of interface categories is possible based on interaction with DHCPv4 [RFC2131] and DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] servers on connected links. HNCP defines special DHCP behavior to differentiate its internal servers from external ones in order to achieve this. Therefore, all internal devices (including HNCP nodes) running DHCP servers on links where auto-detection is used by any HNCP node MUST use the following mechanism based on "The User Class Option for DHCP" [RFC3004] and its DHCPv6 counterpart [RFC3315]:
接続されたリンク上のDHCPv4 [RFC2131]およびDHCPv6プレフィックス委任(DHCPv6-PD)[RFC3633]サーバーとの相互作用に基づいて、インターフェイスカテゴリの自動検出が可能です。 HNCPは、これを実現するために内部サーバーを外部サーバーと区別する特別なDHCP動作を定義しています。したがって、すべてのHNCPノードが自動検出を使用するリンクでDHCPサーバーを実行しているすべての内部デバイス(HNCPノードを含む)は、「DHCPのユーザークラスオプション」[RFC3004]とそのDHCPv6対応[RFC3315]に基づく次のメカニズムを使用する必要があります。 :
o The device MUST ignore or reject DHCP-Requests containing a DHCP user class consisting of the ASCII string "HOMENET".
o デバイスは、ASCII文字列「HOMENET」で構成されるDHCPユーザークラスを含むDHCP要求を無視または拒否する必要があります。
Not following this rule (e.g., running unmodified DHCP servers) might lead to false positives when auto-detection is used, i.e., HNCP nodes assume an interface to not be internal, even though it was intended to be.
このルールに従わない(たとえば、変更されていないDHCPサーバーを実行する)と、自動検出が使用されている場合、つまり、意図されていたとしてもHNCPノードはインターフェースが内部ではないと想定される場合、誤検知が発生する可能性があります。
This section defines the interface classification algorithm. It is suitable for both IPv4 and IPv6 (single or dual stack) and detects the category of an interface either automatically or based on a fixed configuration. By determining the category for all interfaces, the network borders are implicitly defined, i.e., all interfaces not belonging to the External category are considered to be within the borders of the network; all others are not.
このセクションでは、インターフェース分類アルゴリズムを定義します。 IPv4とIPv6の両方(シングルスタックまたはデュアルスタック)に適しており、インターフェイスのカテゴリを自動的に、または固定構成に基づいて検出します。すべてのインターフェースのカテゴリーを決定することにより、ネットワークの境界が暗黙的に定義されます。つまり、外部カテゴリーに属さないすべてのインターフェースは、ネットワークの境界内にあると見なされます。他のすべてはそうではありません。
The following algorithm MUST be implemented by any node implementing HNCP. However, if the node does not implement auto-detection, only the first and last step are required. The algorithm works as follows, with evaluation stopping at first match:
次のアルゴリズムは、HNCPを実装するノードによって実装する必要があります。ただし、ノードが自動検出を実装していない場合は、最初と最後の手順のみが必要です。アルゴリズムは次のように機能し、最初の一致で評価が停止します。
1. If a fixed category is configured for an interface, it is used.
1. 固定カテゴリーがインターフェースに構成されている場合、それが使用されます。
2. If a delegated prefix could be acquired by running a DHCPv6 client, it is considered external. The DHCPv6 client MUST have included a DHCPv6 user class consisting of the ASCII string "HOMENET" in all of its requests.
2. DHCPv6クライアントを実行して委任されたプレフィックスを取得できる場合、それは外部と見なされます。 DHCPv6クライアントは、すべての要求にASCII文字列 "HOMENET"で構成されるDHCPv6ユーザークラスを含んでいる必要があります。
3. If an IPv4 address could be acquired by running a DHCPv4 client on the interface, it is considered external. The DHCPv4 client MUST have included a DHCP user class consisting of the ASCII string "HOMENET" in all of its requests.
3. インターフェイスでDHCPv4クライアントを実行してIPv4アドレスを取得できる場合、そのアドレスは外部と見なされます。 DHCPv4クライアントは、すべてのリクエストにASCII文字列「HOMENET」で構成されるDHCPユーザークラスを含めなければなりません。
4. The interface is considered internal.
4. インターフェイスは内部と見なされます。
Note that as other HNCP nodes will ignore the client due to the User Class option, any server that replies is clearly external (or a malicious internal node).
他のHNCPノードはユーザークラスオプションによりクライアントを無視するため、応答するサーバーは明らかに外部(または悪意のある内部ノード)であることに注意してください。
An HNCP router SHOULD allow setting the fixed category for each interface that may be connected to either an internal or external device (e.g., an Ethernet port that can be connected to a modem, another HNCP router, or a client). Note that all fixed categories except internal and external cannot be auto-detected and can only be selected using manual configuration.
HNCPルーターは、内部デバイスまたは外部デバイス(たとえば、モデム、別のHNCPルーター、またはクライアントに接続できるイーサネットポート)に接続できる各インターフェイスの固定カテゴリを設定できるようにする必要があります(SHOULD)。内部と外部を除くすべての固定カテゴリは自動検出できず、手動設定を使用してのみ選択できることに注意してください。
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.
インターフェースで自動検出を使用するHNCPルーターは、固定カテゴリーのないインターフェースがアクティブである限り(適切に構成されたDHCPクライアントを実行し(自動検出が内部であると見なす状態を含む))、条件に反応するために上記のアルゴリズムを再実行する必要がありますその結果、インターフェースのカテゴリーが異なります。ルーターは、DHCPクライアントがリースを取得できる適切な時間(デフォルトでは5秒)待機してから、新しくアクティブ化されたインターフェースまたは以前の外部インターフェースを内部として扱う必要があります(SHOULD)。
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を使用して構成されます。
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.
ノードは、たとえば、両方のローカルインターフェースの共通リンクの一部である同一のリモートインターフェースを検出することによって、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.
デリゲートされたプレフィックスについて予約済みパーツに関する情報(たとえば、[RFC6603]で指定されている)が受信される場合は常に、予約済みパーツは、割り当てられたプレフィックスTLV(セクション10.3)を使用して、最大の優先度(つまり、15)で、あたかもプライベートリンクに割り当てられました。
Some connections or delegated prefixes may have a special meaning and are not regularly used for internal or Internet connectivity; instead, they may provide access to special services like VPNs, sensor networks, Voice over IP (VoIP), IPTV, etc. Care must be taken that these prefixes are properly integrated and dealt with in the network, in order to avoid breaking connectivity for devices who are not aware of their special characteristics or to only selectively allow certain devices to use them. Such prefixes are distinguished using Prefix-Policy TLVs (Section 10.2.1.1). Their contents MAY be
一部の接続または委任されたプレフィックスには特別な意味があり、内部またはインターネット接続には通常使用されません。代わりに、VPN、センサーネットワーク、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:
HNCPノードに対して部分的に不透明であり、その識別と使用法はローカルポリシーに依存します。ただし、次の一般的なルールを遵守する必要があります。
Special rules apply when making address assignments for prefixes with Prefix-Policy TLVs with type 131, as described in Section 6.3.2.
セクション6.3.2で説明されているように、タイプ131の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)。
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)を定義します。これは、公開された割り当て済みプレフィックスを通知するために使用する必要があります。
All HNCP nodes running the prefix assignment algorithm use the following values for its parameters:
プレフィックス割り当てアルゴリズムを実行するすべてのHNCPノードは、パラメーターに次の値を使用します。
Node IDs: HNCP node identifiers are used. The comparison operation is defined as bitwise comparison.
ノードID:HNCPノードIDが使用されます。比較演算は、ビットごとの比較として定義されます。
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.
共有リンクのセット:内部、リーフ、ゲスト、またはアドホックカテゴリのインターフェースに関連付けられた共通リンクのセット。インターフェースが追加、削除、または1つのカテゴリーから別のカテゴリーに切り替えられると、動的に更新されます。複数のインターフェースが同じ共通リンクに属していることが検出された場合、1つを除くこれらのインターフェースすべてで、プレフィックス割り当てが無効になります。
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:
アドバタイズされたプレフィックスのセット:他のHNCPノードによってアドバタイズされる割り当て済みプレフィックスTLVに含まれるプレフィックスのセット(ローカルノードによってアドバタイズされるプレフィックスはこのセットにはありません)。関連するアドバタイズされたプレフィックスの優先度は、TLVで指定された優先度です。関連する共有リンクは次のように決定されます。
* If the Link Identifier is 0, the Advertised Prefix is not assigned on a Shared Link.
* リンク識別子が0の場合、アドバタイズされたプレフィックスは共有リンクに割り当てられません。
* If the other node's interface identified by the Link Identifier is included in one of the Common Links used for prefix assignment, it is considered as assigned on the given Common Link.
* リンク識別子によって識別される他のノードのインターフェースが、プレフィックス割り当てに使用される共通リンクの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.
アドバタイズされたプレフィックスとそれに関連する優先順位および関連する共有リンクは、割り当て済みプレフィックスTLVが追加、更新、または削除されたとき、および共通リンクが変更されたときに更新する必要があります。
ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix adoption is done instantly).
ADOPT_MAX_DELAY:デフォルト値は0秒です(つまり、接頭辞の採用は即座に行われます)。
BACKOFF_MAX_DELAY: The default value is 4 seconds.
BACKOFF_MAX_DELAY:デフォルト値は4秒です。
RANDOM_SET_SIZE: The default value is 64.
RANDOM_SET_SIZE:デフォルト値は64です。
Flooding Delay: The default value is 5 seconds.
フラッディング遅延:デフォルト値は5秒です。
Default Advertised Prefix Priority: When a new assignment is created or an assignment is adopted -- as specified in the prefix assignment algorithm routine -- the default Advertised Prefix Priority to be used is 2.
デフォルトのアドバタイズされたプレフィックスの優先度:プレフィックス割り当てアルゴリズムルーチンで指定されているように、新しい割り当てが作成されるか割り当てが採用されると、使用されるデフォルトのアドバタイズされたプレフィックスの優先度は2になります。
Whenever the prefix assignment algorithm subroutine (Section 4.1 of [RFC7695]) is run on a Common Link, and whenever a new prefix may be assigned (case 1 of the subroutine: no Best Assignment and no Current Assignment), the decision of whether the assignment of a new prefix is desired MUST follow these rules in order:
プレフィックス割り当てアルゴリズムサブルーチン([RFC7695]のセクション4.1)が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.
プレフィックスの残りの優先ライフタイムが0で、ゼロ以外の優先ライフタイムを持つプレフィックス割り当てに使用される同じIPバージョンの別の委任プレフィックスがある場合、新しいプレフィックスの作成は望ましくありません。
If the Delegated-Prefix TLV does not include a Prefix-Policy TLV indicating restrictive assignment (type 131) or if local policy exists to identify it based on, e.g., other Prefix-Policy TLV values and allows assignment, the creation of a new prefix is desired.
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.
考慮される委任されたプレフィックスがIPv6プレフィックスであり、長さ64の使用可能なプレフィックスが少なくとも1つある場合は、特に構成されていない限り、長さ64のプレフィックスを選択する必要があります。長さ64のプレフィックスが使用できない場合は、構成なしでも、より長いプレフィックスを選択できます(MAY)。
If the considered delegated prefix is an IPv4 prefix (Section 6.5 details how IPv4-delegated prefixes are generated), a prefix of length 24 SHOULD be preferred.
考慮される委任されたプレフィックスがIPv4プレフィックスである場合(セクション6.5は、IPv4委任されたプレフィックスがどのように生成されるかを詳細に説明しています)、長さ24のプレフィックスが推奨されます(SHOULD)。
In any case, an HNCP router making an assignment MUST support a mechanism suitable to distribute addresses from the considered prefix if the link is intended to be used by clients. In this case, a router assigning an IPv4 prefix MUST announce the L-capability, and a router assigning an IPv6 prefix with a length greater than 64 MUST announce the H-capability as defined in Section 4.
いずれの場合も、割り当てを行うHNCPルーターは、リンクがクライアントによって使用されることが意図されている場合、考慮されるプレフィックスからアドレスを配布するのに適したメカニズムをサポートする必要があります。この場合、IPv4プレフィックスを割り当てるルーターはL機能を通知する必要があり、64を超える長さのIPv6プレフィックスを割り当てるルーターは、セクション4で定義されているようにH機能を通知する必要があります。
The prefix assignment algorithm indicates when a prefix is applied to the respective Common Link. When that happens, each router connected to said link:
プレフィックス割り当てアルゴリズムは、プレフィックスがそれぞれの共通リンクにいつ適用されるかを示します。それが起こると、各リンクは上記のリンクに接続しました:
MUST forward traffic destined to said prefix to the respective link.
上記のプレフィックスを宛先とするトラフィックをそれぞれのリンクに転送する必要があります。
MUST participate in the client configuration election as described in Section 7, if the link is intended to be used by clients.
リンクがクライアントによって使用されることが意図されている場合、セクション7で説明されているように、クライアント構成の選択に参加する必要があります。
MAY add an address from said prefix to the respective network interface as described in Section 6.4, e.g., if it is to be used as source for locally originating traffic.
たとえば、ローカルで発信するトラフィックのソースとして使用する場合は、セクション6.4で説明されているように、前述のプレフィックスからそれぞれのネットワークインターフェイスにアドレスを追加できます。
When an HNCP router announcing the P-Capability (Section 4) receives a DHCPv6-PD request from a client, it SHOULD assign one prefix per delegated prefix in the network. This set of assigned prefixes is then delegated to the client, after it has been applied as described in the prefix assignment algorithm. Each DHCPv6-PD client MUST be considered as an independent Private Link, and delegation MUST be based on the same set of delegated prefixes as the one used for Common Link prefix assignments; however, the prefix length to be delegated MAY be smaller than 64.
P機能(セクション4)を通知するHNCPルーターがクライアントからDHCPv6-PD要求を受信すると、ネットワーク内の委任されたプレフィックスごとに1つのプレフィックスを割り当てる必要があります(SHOULD)。この割り当てられたプレフィックスのセットは、プレフィックス割り当てアルゴリズムの説明に従って適用された後、クライアントに委任されます。各DHCPv6-PDクライアントは独立したプライベートリンクと見なす必要があり、委任は、共通リンクプレフィックス割り当てに使用されるものと同じ委任プレフィックスのセットに基づく必要があります。ただし、委任されるプレフィックス長は64未満である場合があります。
The assigned prefixes MUST NOT be given to DHCPv6-PD clients before they are applied and MUST be withdrawn whenever they are destroyed. As an exception to this rule, in order to shorten delays of processed requests, a router MAY prematurely give out a prefix that is advertised but not yet applied if it does so with a valid lifetime of not more than 30 seconds and ensures removal or correction of lifetimes as soon as possible.
割り当てられたプレフィックスは、それらが適用される前にDHCPv6-PDクライアントに与えてはならず(MUST)、それらが破棄されるときはいつでも撤回する必要があります。このルールの例外として、処理されたリクエストの遅延を短縮するために、ルーターは、有効期間が30秒以下である場合、アドバタイズされているがまだ適用されていないプレフィックスを時期尚早に提供し、削除または修正を保証する場合があります。寿命のできるだけ早く。
This section specifies how HNCP nodes reserve addresses for their own use. Nodes MAY, at any time, try to reserve a new address from any Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6 address and -- if it supports IPv4 -- MUST announce an IPv4 address, whenever matching prefixes are assigned to at least one of its Common Links. These addresses are published using Node-Address TLVs and used to locally reach HNCP nodes for other services. Nodes SHOULD NOT create and announce more than one assignment per IP version to avoid cluttering the node data with redundant information unless a special use case requires it.
このセクションでは、HNCPノードが自分用にアドレスを予約する方法を指定します。ノードは、いつでも、適用された割り当て済みプレフィックスから新しいアドレスを予約しようとする場合があります。各HNCPノードはIPv6アドレスを通知する必要があり(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 192.0.2.0/24 is assigned and applied to a Common Link, addresses included in 192.0.2.0/26 are reserved for HNCP nodes, and the remaining addresses are reserved for the elected DHCPv4 server.
意味論的に不透明なインターフェイス識別子に基づくステートレス割り当て[RFC7217]可能な場合は常にアドレス割り当てに使用する必要があります(たとえば、プレフィックスの長さは64)。ステートレス割り当てが使用されない場合、アドレスの最初の4分の1はHNCPベースのアドレス割り当て用に予約されますが、最後の4分の3はDHCP選定ルーターに任されます(セクション4はDHCPサーバー選定プロセスを指定します)。たとえば、プレフィックス192.0.2.0/24が割り当てられ、共通リンクに適用される場合、192.0.2.0 / 26に含まれるアドレスはHNCPノード用に予約され、残りのアドレスは選択されたDHCPv4サーバー用に予約されます。
HNCP nodes assign addresses to themselves and then (to ensure eventual lack of conflicting assignments) publish the assignments using the Node-Address TLV (Section 10.4).
HNCPノードは自分自身にアドレスを割り当て、次に(競合する割り当ての最終的な欠如を確実にするために)ノードアドレスTLVを使用して割り当てを公開します(セクション10.4)。
The process of obtaining addresses is specified as follows:
アドレスを取得するプロセスは、次のように指定されます。
o A node MUST NOT start advertising an address if it is already advertised by another node.
o アドレスが別のノードによってすでにアドバタイズされている場合、ノードはアドレスのアドバタイズを開始してはなりません。
o An assigned address MUST be part of an assigned prefix currently applied on a Common Link that includes the interface specified by the endpoint identifier.
o 割り当てられたアドレスは、エンドポイント識別子によって指定されたインターフェースを含む共通リンクに現在適用されている割り当てられたプレフィックスの一部である必要があります。
o An address MUST NOT be used unless it has been advertised for at least ADDRESS_APPLY_DELAY consecutive seconds and is still currently being advertised. The default value for ADDRESS_APPLY_DELAY is 3 seconds.
o アドレスが少なくとも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 同じアドレスが複数のノードによってアドバタイズされる場合は常に、最大のノード識別子を持つノードによってアドバタイズされたものを除くすべてを削除する必要があります。
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.
HNCPルーターは、ネットワークへのIPv4インターネット接続を提供したいときはいつでもプライベートIPv4プレフィックス[RFC1918]を作成する必要があり、インターネット接続を持つ他のプライベートIPv4プレフィックスは現在存在しません。また、IPv4プレフィックスが存在しない場合はプライベートIPv4プレフィックスを作成して、ローカルIPv4接続を有効にすることもできますが、それ以外の場合は行わないでください。複数のIPv4プレフィックスがアナウンスされた場合、最大のノード識別子を持つノードによって公開されたプレフィックスのみが、タイプ0のプレフィックスポリシーTLVがあるものの中で保持されます(存在する場合)。インターネット接続でプレフィックスを公開するルーターは、IPv4トラフィックをインターネットに転送し、プレフィックスを公開する限り、ネットワークに代わってNATを実行する必要があります。ネットワーク内の他のルーターは、選択しない場合があります。
Creation of such ULA and IPv4 prefixes MUST be delayed by a random time span between 0 and 10 seconds in which the router MUST scan for others trying to do the same.
そのようなULAおよびIPv4プレフィックスの作成は、ルーターが同じことを試みる他のものをスキャンしなければならない0から10秒の間のランダムなタイムスパンだけ遅延する必要があります。
When a new ULA prefix is created, the prefix is selected based on the configuration, using the last non-deprecated ULA prefix, or generated based on [RFC4193].
新しいULAプレフィックスが作成されると、プレフィックスは構成に基づいて、最後の非推奨のULAプレフィックスを使用して選択されるか、[RFC4193]に基づいて生成されます。
HNCP routers need to ensure that hosts and non-HNCP downstream routers on internal links are configured with addresses and routes. Since DHCP clients can usually only bind to one server at a time, a per-link and per-service election takes place.
HNCPルーターは、内部リンク上のホストと非HNCPダウンストリームルーターがアドレスとルートで構成されていることを確認する必要があります。 DHCPクライアントは通常、一度に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.
HNCPルーターには、ダウンストリームデバイスを構成し、ネーミングサービスを提供するためのさまざまな機能があります。したがって、各ルーターは、選挙の候補として参加するために、セクション4で指定されているようにその機能を示さなければなりません(MUST)。
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.
一般に、ステートレスアドレス自動構成[RFC4861]は、オーバーヘッドが低く、再番号付け機能が速いため、クライアント構成に使用されます。したがって、各HNCPルーターは、クライアントが使用することを目的としたインターフェイスでルーターアドバタイズメントを送信し、そのようなすべてのアドバタイズメントでそれぞれのリンクに割り当てた各適用割り当てプレフィックスのプレフィックス情報オプションを少なくとも含める必要があります。ただし、管理上の選択により、ステートフルDHCPv6をさらに使用して、たとえば、ホスト名を収集し、それらを使用してネーミングサービスを提供したり、ステートレス構成が適用できない場合に使用したりできます。
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.
共通リンク(セクション6.1)に指定されたステートフルDHCPv6サーバーは、セクション4で説明されている機能に基づいて選出されます。勝者は、最大のH機能をアドバタイズするルーター(共通リンクに接続)です。同数の場合、機能値(セクション4)が比較され、最大値を持つルーターが選択されます。別のタイの場合、最大のノード識別子を持つルータが、機能値がタイであるルータの中から選出されます。
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サーバーとして選出されるのをやめたルーターは、クライアントの再構成をトリガーするために、残りの既存のバインディングを無効にする必要があります(該当する場合)。
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.
共通リンクのプレフィックス委任用に指定されたDHCPv6サーバーは、セクション4で説明されている機能に基づいて選出されます。勝者は、最大のP機能をアドバタイズするルーター(共通リンクに接続されている)です。同数の場合、機能値(セクション4)が比較され、最大値を持つルーターが選択されます。別のタイの場合、最大のノード識別子を持つルータが、機能値がタイであるルータの中から選出されます。
The elected router MUST provide prefix delegation services [RFC3633] on the given link (and follow the rules in Section 6.3.4); all other nodes MUST NOT.
選ばれたルーターは与えられたリンクでプレフィックス委任サービス[RFC3633]を提供しなければなりません(そしてセクション6.3.4のルールに従ってください)。他のすべてのノードは、してはなりません。
The designated DHCPv4 server on a Common Link (Section 6.1) is elected based on the capabilities described in Section 4. The winner is the router (connected to the Common Link) advertising the greatest L-capability. In case of a tie, Capability Values (Section 4) are compared, and the router with the greatest value is elected. In case of another tie, the router with the greatest node identifier is elected among the routers with tied Capability Values.
共通リンク(セクション6.1)上の指定されたDHCPv4サーバーは、セクション4で説明されている機能に基づいて選出されます。勝者は、最大のL機能をアドバタイズする(共通リンクに接続された)ルーターです。同数の場合、機能値(セクション4)が比較され、最大値を持つルーターが選択されます。別のタイの場合、最大のノード識別子を持つルータが、機能値がタイであるルータの中から選出されます。
The elected router MUST provide DHCPv4 services on the given link; all other nodes MUST NOT. The elected router MUST provide IP addresses from the pool defined in Section 6.4 and MUST announce itself as router [RFC2132] to clients.
選出されたルーターは、所定のリンクでDHCPv4サービスを提供する必要があります。他のすべてのノードは、してはなりません。選出されたルーターは、セクション6.4で定義されたプールからIPアドレスを提供しなければならず(MUST)、それ自体をルーター[RFC2132]としてクライアントに通知しなければなりません。
DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short (i.e., not longer than 5 minutes) in order to provide reasonable response times to changes. Routers that cease to be elected DHCP servers SHOULD -- when applicable -- invalidate remaining existing bindings in order to trigger client reconfiguration.
DHCPv4ライフタイムの更新と再バインド時間(T1とT2)は、変更に対する適切な応答時間を提供するために、短く(つまり、5分以内)する必要があります。 DHCPサーバーとして選出されるのをやめたルーターは、クライアントの再構成をトリガーするために、残りの既存のバインディングを無効にする必要があります(該当する場合)。
The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link is elected based on the capabilities described in Section 4. The winner is the router (connected to the Common Link) advertising the greatest M-capability. In case of a tie, Capability Values (Section 4) are compared, and the router with the greatest value is elected. In case of another tie, the router with the greatest node identifier is elected among the routers with tied Capability Values.
共通リンク上の指定されたマルチキャストDNS(mDNS)[RFC6762]プロキシは、セクション4で説明されている機能に基づいて選出されます。勝者は、最大のM機能をアドバタイズするルーター(共通リンクに接続)です。同数の場合、機能値(セクション4)が比較され、最大値を持つルーターが選択されます。別のタイの場合、最大のノード識別子を持つルータが、機能値がタイであるルータの中から選出されます。
The elected router MUST provide an mDNS proxy on the given link and announce it as described in Section 8.
選出されたルーターは、所定のリンクにmDNSプロキシを提供し、セクション8で説明されているようにそれを通知しなければなりません(MUST)。
Network-wide naming and service discovery can greatly improve the user friendliness of a network. The following mechanism provides means to setup and delegate naming and service discovery across multiple HNCP routers.
ネットワーク全体にわたるネーミングとサービスディスカバリにより、ネットワークの使いやすさが大幅に向上します。次のメカニズムは、複数のHNCPルーター間でネーミングとサービス検出をセットアップおよび委任する手段を提供します。
Each HNCP router SHOULD provide and advertise a recursive name resolving server to clients that honor the announcements made in Delegated-Zone TLVs (Section 10.5), Domain-Name TLVs (Section 10.6), and Node-Name TLVs (Section 10.7), i.e., delegate queries to the designated name servers and hand out appropriate A, AAAA, and PTR records according to the mentioned TLVs.
各HNCPルーターは、委任ゾーンTLV(セクション10.5)、ドメイン名TLV(セクション10.6)、およびノード名TLV(セクション10.7)、つまり指定されたネームサーバーにクエリを委任し、前述のTLVに従って適切なA、AAAA、およびPTRレコードを配布します。
Each HNCP router SHOULD provide and announce an auto-generated or user-configured name for each internal Common Link (Section 6.1) for which it is the designated DHCPv4, stateful DHCPv6 server, mDNS proxy, or for which it provides forward or reverse DNS services on behalf of connected devices. This announcement is done using Delegated-Zone TLVs (Section 10.5) and MUST be unique in the whole network. In case of a conflict, the announcement of the node with the greatest node identifier takes precedence, and all other nodes MUST cease to announce the conflicting TLV. HNCP routers providing recursive name resolving services MUST use the included DNS server 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)。複数がアナウンスされる場合、最大のノード識別子を持つノードのドメインが優先されます。
PSKs are often required to secure (for example) IGPs and other protocols that lack support for asymmetric security. The following mechanism manages PSKs using HNCP to enable bootstrapping of such third-party protocols. The scheme SHOULD NOT be used unless it's in conjunction with secured HNCP unicast transport (i.e., DTLS), as transferring the PSK in plaintext anywhere in the network is a potential risk, especially as the originator may not know about security (and use of DNCP security) on all links. The following rules define how such a PSK is managed and used:
多くの場合、PSKは(たとえば)IGPや非対称セキュリティをサポートしていないその他のプロトコルを保護するために必要です。次のメカニズムは、そのようなサードパーティのプロトコルのブートストラップを可能にするためにHNCPを使用してPSKを管理します。セキュアなHNCPユニキャストトランスポート(DTLS)と併用しない限り、このスキームは使用しないでください。ネットワーク内のどこかでPSKをプレーンテキストで転送することは、特に発信者がセキュリティ(およびDNCPの使用)を知らない可能性があるため、潜在的なリスクです。セキュリティ)すべてのリンク。次のルールは、そのようなPSKの管理方法と使用方法を定義しています。
o If no Managed-PSK TLV (Section 10.8) is currently being announced, an HNCP node using this mechanism MUST create one after a random delay of 0 to 10 seconds with a 32 bytes long random key and add it to its node data.
o 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が変更されるたびに更新する必要があります。
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.
ここで定義されたTLVは、指定されたコンテキストで表示される場合にのみ有効です。つまり、定義で言及されているコンテナーTLV内に直接、または-言及がない場合は、ノードデータセット内のトップレベルのTLVとしてのみ有効です。指定されたコンテキストの外側に表示されるTLVは無視する必要があります。
TLVs encoding IP addresses or prefixes allow encoding both IPv6 and IPv4 addresses and prefixes. IPv6 information is encoded as is, whereas for IPv4, the IPv4-mapped IPv6 addresses format [RFC4291] is used, and prefix lengths are encoded as the original IPv4 prefix length increased by 96.
IPアドレスまたはプレフィックスをエンコードするTLVでは、IPv6とIPv4の両方のアドレスとプレフィックスをエンコードできます。 IPv6情報はそのままエンコードされますが、IPv4の場合、IPv4にマッピングされたIPv6アドレス形式[RFC4291]が使用され、プレフィックス長は、元のIPv4プレフィックス長が96増加したときにエンコードされます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: HNCP-Version (32) | Length: >= 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | M | P | H | L | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User-agent |
This TLV is used to indicate the supported version and router capabilities of an HNCP node as described in Section 4.
このTLVは、セクション4で説明されているように、サポートされているバージョンとHNCPノードのルーター機能を示すために使用されます。
Reserved: Bits are reserved for future use. They MUST be set to 0 when creating this TLV, and their value MUST be ignored when processing the TLV.
予約済み:ビットは将来の使用のために予約されています。このTLVを作成するときはこれらを0に設定する必要があり、TLVを処理するときはその値を無視する必要があります。
M-capability: Priority value used for electing the on-link mDNS [RFC6762] proxy. It MUST be set to 0 if the router is not capable of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use.
M-capability:リンク上の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.
P機能:リンク上のDHCPv6-PDサーバーを選択するために使用される優先度の値。ルータがDHCPv6-PD(セクション6.3.4)を介してプレフィックスを提供できない場合は0に設定する必要があります。それ以外の場合は4に設定する必要がありますが、デフォルト以外であることを示すために1から7までの任意の値に設定できます(MAY)優先。値8〜15は、将来の使用のために予約されています。
H-capability: Priority value used for electing the on-link DHCPv6 server offering non-temporary addresses. It MUST be set to 0 if the router is not capable of providing such addresses, otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use.
H機能:非一時アドレスを提供するオンリンクDHCPv6サーバーを選択するために使用される優先度の値。ルータがそのようなアドレスを提供できない場合は0に設定する必要があります。それ以外の場合は4に設定する必要がありますが、デフォルト以外の優先度を示すために1から7までの任意の値に設定する必要があります。値8〜15は、将来の使用のために予約されています。
L-capability: Priority value used for electing the on-link DHCPv4 server. It MUST be set to 0 if the router is not capable of running a legacy DHCPv4 server offering IPv4 addresses to clients, otherwise it SHOULD be set to 4 but MAY be set to any value from 1
L機能:オンリンクDHCPv4サーバーの選択に使用される優先度の値。ルータがIPv4アドレスをクライアントに提供するレガシーDHCPv4サーバーを実行できない場合は0に設定する必要があります。それ以外の場合は4に設定する必要がありますが、1からの任意の値に設定できます(MAY)
to 7 to indicate a non-default priority. The values 8-15 are reserved for future use.
7からデフォルト以外の優先順位を示します。値8〜15は、将来の使用のために予約されています。
User-Agent: The user-agent is a human-readable UTF-8 string that describes the name and version of the current HNCP implementation.
User-Agent:user-agentは、現在のHNCP実装の名前とバージョンを説明する、人間が読めるUTF-8文字列です。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: External-Connection (33)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Optional nested TLVs) |
An External-Connection TLV is a container TLV used to gather network configuration information associated with a single external connection (Section 6.2) to be shared across the HNCP network. A node MAY publish an arbitrary number of instances of this TLV to share the desired number of external connections. Upon reception, the information transmitted in any nested TLVs is used for the purposes of prefix assignment (Section 6.3) and host configuration (Section 7).
外部接続TLVは、HNCPネットワーク全体で共有される単一の外部接続(セクション6.2)に関連付けられたネットワーク構成情報を収集するために使用されるコンテナーTLVです。ノードは、必要な数の外部接続を共有するために、このTLVの任意の数のインスタンスを公開する場合があります。受信すると、ネストされたTLVで送信された情報は、プレフィックス割り当て(セクション6.3)およびホスト構成(セクション7)の目的で使用されます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Delegated-Prefix (34) | Length: >= 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime Since Origination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime Since Origination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | | +-+-+-+-+-+-+-+-+ Prefix + ... | | 0-pad if any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Optional nested TLVs) |
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.
発信以降の有効な存続期間:このTLVを含むノードデータの発信時に、委任されたプレフィックスが有効であった時間(秒)。この値は、ノードがノード状態TLVを再発行するたびに更新する必要があります。
Preferred Lifetime Since Origination: The time in seconds the delegated prefix was preferred for at the origination time of the node data containing this TLV. The value MUST be updated whenever the node republishes its Node-State TLV.
発信以降の優先寿命:このTLVを含むノードデータの発信時に、委任されたプレフィックスが優先された秒単位の時間。この値は、ノードがノード状態TLVを再発行するたびに更新する必要があります。
Prefix Length: The number of significant bits in the prefix.
プレフィックス長:プレフィックスの有効ビット数。
Prefix: Significant bits of the prefix padded with zeros up to the next byte boundary.
プレフィックス:次のバイト境界までゼロが埋め込まれたプレフィックスの有効ビット。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Prefix-Policy (43) | Length: >= 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Policy Type | | +-+-+-+-+-+-+-+-+ Value + | |
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).
0:インターネット接続(値なし)。
1-128: Explicit destination prefix with the Policy Type being the actual length of the prefix and the value containing significant bits of the destination prefix padded with zeros up to the next byte boundary.
1-128:明示的な宛先プレフィックス。ポリシータイプはプレフィックスの実際の長さであり、次のバイト境界までゼロが埋め込まれた宛先プレフィックスの有効ビットを含む値です。
129: DNS domain. The value contains a DNS label sequence encoded per [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label.
129:DNSドメイン。この値には、[RFC1035]に従ってエンコードされたDNSラベルシーケンスが含まれています。圧縮は使用してはなりません。ラベルシーケンスは空のラベルで終了する必要があります。
130: Opaque UTF-8 string (e.g., for administrative purposes).
130:不透明なUTF-8文字列(管理目的など)。
131: Restrictive assignment (no value).
131:制限付き割り当て(値なし)。
132-255: Reserved for future additions.
132-255:将来の追加のために予約されています。
Value: A variable-length identifier of the given type.
値:指定されたタイプの可変長の識別子。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: DHCPv6-Data (37) | Length: > 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHCPv6 option stream |
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].
DHCPv6オプションストリーム:[RFC3315]で指定されているようにエンコードされたDHCPv6オプション。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: DHCPv4-Data (38) | Length: > 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHCPv4 option stream |
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].
DHCPv4オプションストリーム:[RFC2131]で指定されているようにエンコードされたDHCPv4オプション。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Assigned-Prefix (35) | Length: >= 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsv. | Prty. | Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + ... | | 0-pad if any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Optional nested TLVs) |
This TLV is used to announce Published Assigned Prefixes for the purposes of prefix assignment (Section 6.3).
このTLVは、プレフィックス割り当ての目的でパブリッシュされた割り当て済みプレフィックスをアナウンスするために使用されます(セクション6.3)。
Endpoint Identifier: The endpoint identifier of the local interface the prefix is assigned to, or 0 if it is assigned to a Private Link (e.g., when the prefix is assigned for downstream prefix delegation).
エンドポイント識別子:プレフィックスが割り当てられているローカルインターフェイスのエンドポイント識別子、またはプライベートリンクに割り当てられている場合は0(たとえば、プレフィックスがダウンストリームプレフィックス委任に割り当てられている場合)。
Rsv.: Bits are reserved for future use. They MUST be set to 0 when creating this TLV, and their value MUST be ignored when processing the TLV.
Rsv .:ビットは将来の使用のために予約されています。このTLVを作成するときはこれらを0に設定する必要があり、TLVを処理するときはその値を無視する必要があります。
Prty: The Advertised Prefix Priority from 0 to 15.
Prty:0から15のアドバタイズされたプレフィックスの優先度。
0-1: Low priorities.
0-1:低優先度。
2: Default priority.
2:デフォルトの優先度。
3-7: High priorities.
3-7:優先度が高い。
8-11: Administrative priorities. MUST NOT be used unless configured otherwise.
8-11:管理上の優先順位。特に設定しない限り、使用してはなりません。
12-14: Reserved for future use.
12-14:将来の使用のために予約されています。
15: Provider priorities. MAY only be used by the router advertising the corresponding delegated prefix and based on static or dynamic configuration (e.g., for excluding a prefix based on the DHCPv6-PD Prefix Exclude Option [RFC6603]).
15:プロバイダーの優先順位。対応する委任されたプレフィックスをアドバタイズし、静的または動的構成に基づくルーターでのみ使用できます(たとえば、DHCPv6-PDプレフィックス除外オプション[RFC6603]に基づくプレフィックスを除外するため)。
Prefix Length: The number of significant bits in the Prefix field.
プレフィックス長:プレフィックスフィールドの有効ビット数。
Prefix: The significant bits of the prefix padded with zeros up to the next byte boundary.
プレフィックス:次のバイト境界までゼロが埋め込まれたプレフィックスの有効ビット。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Node-Address (36) | Length: 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Optional nested TLVs) |
This TLV is used to announce addresses assigned to an HNCP node as described in Section 6.4.
このTLVは、セクション6.4で説明されているようにHNCPノードに割り当てられたアドレスを通知するために使用されます。
Endpoint Identifier: The endpoint identifier of the local interface the prefix is assigned to, or 0 if it is not assigned on an HNCP enabled link.
エンドポイント識別子:プレフィックスが割り当てられているローカルインターフェイスのエンドポイント識別子、またはHNCP対応リンクに割り当てられていない場合は0。
IP Address: The globally scoped IPv6 address, or the IPv4 address encoded as an IPv4-mapped IPv6 address [RFC4291].
IPアドレス:グローバルスコープのIPv6アドレス、またはIPv4にマップされたIPv6アドレス[RFC4291]としてエンコードされたIPv4アドレス。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: DNS-Delegated-Zone (39) | Length: >= 17 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Reserved |L|B|S| | +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | ... | | 0-pad if any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Optional nested TLVs) |
This TLV is used to announce a forward or reverse DNS zone delegation in the HNCP network. Its meaning is roughly equivalent to specifying an NS and A/AAAA record for said zone. Details are specified in Section 8.
このTLVは、HNCPネットワークでフォワードまたはリバースDNSゾーン委任を通知するために使用されます。その意味は、そのゾーンのNSおよびA / AAAAレコードを指定することとほぼ同じです。詳細はセクション8で指定します。
IP Address: The IPv6 address of the authoritative DNS server for the zone; IPv4 addresses are represented as IPv4-mapped addresses [RFC4291]. The special value of :: (all zeros) means the delegation is available in the global DNS hierarchy.
IPアドレス:ゾーンの権威DNSサーバーのIPv6アドレス。 IPv4アドレスは、IPv4マップアドレス[RFC4291]として表されます。特別な値の::(すべてゼロ)は、委任がグローバルDNS階層で使用できることを意味します。
Reserved: Those bits MUST be set to 0 when creating the TLV and ignored when parsing it unless defined in a later specification.
予約済み:これらのビットは、TLVの作成時に0に設定する必要があり、後の仕様で定義されていない限り、解析時に無視する必要があります。
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.
ゾーン:[RFC1035]に従ってエンコードされたラベルシーケンス。圧縮は使用してはなりません。ラベルシーケンスは空のラベルで終了する必要があります。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Domain-Name (40) | Length: > 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain (DNS label sequence - variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to indicate the base domain name for the network as specified in Section 8. This TLV MUST NOT be announced unless the domain name was explicitly configured by an administrator.
このTLVは、セクション8で指定されているネットワークのベースドメイン名を示すために使用されます。ドメイン名が管理者によって明示的に構成されていない限り、このTLVは通知されません。
Domain: The label sequence encoded according to [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label.
ドメイン:[RFC1035]に従ってエンコードされたラベルシーケンス。圧縮は使用してはなりません。ラベルシーケンスは空のラベルで終了する必要があります。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Node-Name (41) | Length: > 17 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Name | ... | (not null-terminated, variable length) | 0-pad if any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Optional nested TLVs) |
This TLV is used to assign the name of a node in the network to a certain IP address as specified in Section 8.
このTLVは、セクション8で指定されているように、ネットワーク内のノードの名前を特定のIPアドレスに割り当てるために使用されます。
IP Address: The IP address associated with the name. IPv4 addresses are encoded using IPv4-mapped IPv6 addresses.
IPアドレス:名前に関連付けられたIPアドレス。 IPv4アドレスは、IPv4でマップされたIPv6アドレスを使用してエンコードされます。
Length: The length of the name (0-63).
長さ:名前の長さ(0-63)。
Name: The name of the node as a single DNS label.
名前:単一のDNSラベルとしてのノードの名前。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: Managed-PSK (42) | Length: 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Random 256-bit PSK | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Optional nested TLVs) |
This TLV is used to announce a PSK for securing third-party protocols exclusively supporting symmetric cryptography as specified in Section 9.
このTLVは、セクション9で指定されている対称暗号化のみをサポートするサードパーティのプロトコルを保護するためのPSKをアナウンスするために使用されます。
Each node implementing HNCP is subject to the following requirements:
HNCPを実装する各ノードには、次の要件があります。
o It MUST implement HNCP versioning (Section 4) and interface classification (Section 5).
o HNCPバージョニング(セクション4)およびインターフェース分類(セクション5)を実装する必要があります。
o It MUST implement and run the method for securing third-party protocols (Section 9) whenever it uses the security mechanism of HNCP.
o HNCPのセキュリティメカニズムを使用する場合は常に、サードパーティプロトコル(セクション9)を保護するためのメソッドを実装して実行する必要があります。
If the node is acting as a router, then the following requirements apply in addition:
ノードがルーターとして機能している場合は、さらに次の要件が適用されます。
o It MUST support Autonomous Address Configuration (Section 6) and configuration of hosts and non-HNCP routers (Section 7).
o 自律アドレス構成(セクション6)およびホストと非HNCPルーターの構成(セクション7)をサポートする必要があります。
o It SHOULD implement support for naming and service discovery (Section 8) as defined in this document.
o このドキュメントで定義されているように、命名とサービス検出(セクション8)のサポートを実装する必要があります(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時間経過すると省略できます。
HNCP enables self-configuring networks, requiring as little user intervention as possible. However, this zero-configuration goal usually conflicts with security goals and introduces a number of threats.
HNCPは自己構成ネットワークを可能にし、ユーザーの介入をできるだけ少なくします。ただし、この構成不要の目標は通常、セキュリティの目標と競合し、多くの脅威をもたらします。
General security issues for existing home networks are discussed in [RFC7368]. The protocols used to set up addresses and routes in such networks to this day rarely have security enabled within the configuration protocol itself. However, these issues are out of scope for the security of HNCP itself.
既存のホームネットワークの一般的なセキュリティ問題については、[RFC7368]で説明されています。このようなネットワークで今日までアドレスとルートを設定するために使用されるプロトコルでは、構成プロトコル内でセキュリティが有効になっていることはほとんどありません。ただし、これらの問題はHNCP自体のセキュリティの範囲外です。
HNCP is a DNCP-based state synchronization mechanism carrying information with varying threat potential. For this consideration, the payloads defined in DNCP and this document are reviewed:
HNCPは、脅威の可能性が変化する情報を運ぶDNCPベースの状態同期メカニズムです。この考慮のために、DNCPとこのドキュメントで定義されているペイロードを確認します。
o Network topology information such as HNCP nodes and their common links.
o HNCPノードおよびそれらの共通リンクなどのネットワークトポロジ情報。
o Address assignment information such as delegated and assigned prefixes for individual links.
o 個々のリンクの委任および割り当てられたプレフィックスなどのアドレス割り当て情報。
o Naming and service discovery information such as auto-generated or customized names for individual links and nodes.
o 個々のリンクとノードの自動生成された名前やカスタマイズされた名前などの名前付けとサービス検出情報。
As described in Section 5.3, an HNCP node determines the internal or external state on a per-interface basis. A firewall perimeter is set up for the external interfaces, and for internal interfaces, HNCP traffic is allowed, with the exception of the Leaf and Guest subcategories.
セクション5.3で説明されているように、HNCPノードはインターフェースごとに内部または外部の状態を決定します。ファイアウォール境界が外部インターフェース用に設定されており、内部インターフェースの場合、リーフとゲストのサブカテゴリーを除いてHNCPトラフィックが許可されます。
Threats concerning automatic interface classification cannot be mitigated by encrypting or authenticating HNCP traffic itself since external routers do not participate in the protocol and often cannot be authenticated by other means. These threats include propagation of forged uplinks in the homenet in order to, e.g., redirect traffic destined to external locations and forged internal status by external routers to, e.g., circumvent the perimeter firewall.
外部ルーターはプロトコルに参加していないため、他の方法では認証できないことが多いため、自動インターフェイス分類に関する脅威は、HNCPトラフィック自体を暗号化または認証することで軽減できません。これらの脅威には、たとえば、外部の宛先に向けられたトラフィックや外部ルーターによる偽造された内部ステータスをリダイレクトして、たとえば境界ファイアウォールを回避するために、ホームネット内の偽のアップリンクの伝播が含まれます。
It is therefore imperative to either secure individual links on the physical or link layer or preconfigure the adjacent interfaces of HNCP routers to an appropriate fixed category in order to secure the homenet border. Depending on the security of the external link, eavesdropping, man-in-the-middle, and similar attacks on external traffic can still happen between a homenet border router and the ISP; however, these cannot be mitigated from inside the homenet. For example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 messages, but this is very rarely implemented in large or small networks. Further, while PPP can provide secure authentication of both sides of a point-to-point link, it is most often deployed with one-way authentication of the subscriber to the ISP, not the ISP to the subscriber.
したがって、ホームネット境界を保護するために、物理層またはリンク層の個々のリンクを保護するか、適切な固定カテゴリにHNCPルーターの隣接インターフェイスを事前構成することが不可欠です。外部リンクのセキュリティによっては、ホームネット境界ルーターとISPの間で、盗聴、中間者攻撃、および同様の外部トラフィック攻撃が依然として発生する可能性があります。ただし、これらはホームネット内から軽減することはできません。たとえば、DHCPv4はDHCPv4メッセージを認証するために[RFC3118]を定義していますが、これが大規模または小規模のネットワークに実装されることはほとんどありません。さらに、PPPはポイントツーポイントリンクの両側の安全な認証を提供できますが、ほとんどの場合、加入者へのISPではなく、ISPへの加入者の一方向認証で展開されます。
Once the homenet border has been established, there are several ways to secure HNCP against internal threats like manipulation or eavesdropping by compromised devices on a link that is enabled for HNCP traffic. If left unsecured, attackers may perform arbitrary traffic redirection, eavesdropping, spoofing, or denial-of-service attacks on HNCP services such as address assignment or service discovery, and the protocols are secured using HNCP-derived keys such as routing protocols.
ホームネット境界が確立されると、HNCPトラフィックが有効になっているリンク上の侵害されたデバイスによる操作や盗聴などの内部の脅威からHNCPを保護する方法がいくつかあります。安全でないままにしておくと、攻撃者は任意のトラフィックのリダイレクト、盗聴、なりすまし、またはアドレス割り当てやサービス検出などのHNCPサービスに対するサービス拒否攻撃を実行する可能性があり、プロトコルはルーティングプロトコルなどのHNCP派生鍵を使用して保護されます。
Detailed interface categories like "Leaf" or "Guest" can be used to integrate not fully trusted devices to various degrees into the homenet by not exposing them to HNCP traffic or by using firewall rules to prevent them from reaching homenet-internal resources.
「リーフ」や「ゲスト」などの詳細なインターフェースカテゴリを使用して、完全に信頼されていないデバイスをさまざまな程度でホームネットに統合することができます。これらのデバイスをHNCPトラフィックに公開しないか、ファイアウォールルールを使用して、ホームネット内部のリソースに到達しないようにします。
On links where this is not practical and lower layers do not provide adequate protection from attackers, DTLS-based secure unicast transport MUST be used to secure traffic.
これが実用的ではなく、下位層が攻撃者からの十分な保護を提供しないリンクでは、トラフィックを保護するためにDTLSベースの安全なユニキャストトランスポートを使用する必要があります。
IGPs and other protocols are usually run alongside HNCP; therefore, the individual security aspects of the respective protocols must be considered. It can, however, be summarized that many protocols to be run in the home (like IGPs) provide -- to a certain extent -- similar 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.
IGPと他のプロトコルは通常HNCPと共に実行されます。したがって、それぞれのプロトコルの個々のセキュリティの側面を考慮する必要があります。ただし、家庭で実行される多くのプロトコル(IGPなど)は、ある程度、同様のセキュリティメカニズムを提供すると要約できます。これらのプロトコルのほとんどは暗号化をサポートせず、事前共有キーに基づく認証のみをネイティブでサポートします。通常、ホームネットルーティング情報は暗号化されないため、これはHNCPによって展開される暗号化ベースのセキュリティメカニズムの有効性に影響します。
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
32:HNCPバージョン
33: External-Connection
33:外部接続
34: Delegated-Prefix
34:デリゲートプレフィックス
35: Assigned-Prefix
35:割り当てられたプレフィックス
36: Node-Address
36:ノードアドレス
37: DHCPv4-Data
37:DHCPv4-Data
38: DHCPv6-Data
38:DHCPv6-Data
39: DNS-Delegated-Zone
39:DNS委任ゾーン
40: Domain-Name
40:ドメイン名
41: Node-Name
41: のでーなめ
42: Managed-PSK
42:マネージドPSK
43: Prefix-Policy
43:プレフィックスポリシー
44-511: Unassigned.
44-511:未割り当て。
768-1023: Reserved for Private Use. This range is used by HNCP for per-implementation experimentation. How collisions are avoided is outside the scope of this document.
768-1023:私的使用のために予約済み。この範囲は、実装ごとの実験のためにHNCPによって使用されます。衝突を回避する方法は、このドキュメントの範囲外です。
IANA has registered the UDP port numbers 8231 (service name: hncp-udp-port, description: HNCP) and 8232 (service name: hncp-dtls-port, description: HNCP over DTLS), as well as an IPv6 link-local multicast address FF02:0:0:0:0:0:0:11 (description: All-Homenet-Nodes).
IANAは、UDPポート番号8231(サービス名:hncp-udp-port、説明:HNCP)および8232(サービス名:hncp-dtls-port、説明:HNCP over DTLS)、およびIPv6リンクローカルマルチキャストを登録しましたアドレスFF02:0:0:0:0:0:0:11(説明:All-Homenet-Nodes)。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<http://www.rfc-editor.org/info/rfc1321>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<http://www.rfc-editor.org/info/rfc2132>。
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B., and J. Privat, "The User Class Option for DHCP", RFC 3004, DOI 10.17487/RFC3004, November 2000, <http://www.rfc-editor.org/info/rfc3004>.
[RFC3004] Stump、G.、Droms、R.、Gu、Y.、Vyaghrapuri、R.、Demirtjis、A.、Beser、B.、and J. Privat、 "The User Class Option for DHCP"、RFC 3004、 DOI 10.17487 / RFC3004、2000年11月、<http://www.rfc-editor.org/info/rfc3004>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6(DHCPv6)"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル(DHCP)バージョン6のIPv6プレフィックスオプション」、RFC 3633、DOI 10.17487 / RFC3633、2003年12月、<http://www.rfc-editor。 org / info / rfc3633>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<http://www.rfc-editor.org/info/rfc4193>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6(IPv6)」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http:/ /www.rfc-editor.org/info/rfc4861>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>.
[RFC6092] Woodyatt、J.、Ed。、 "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 -editor.org/info/rfc6092>。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6206] Levis、P.、Clauseen、T.、Hui、J.、Gnawali、O。、およびJ. Ko、「The Trickle Algorithm」、RFC 6206、DOI 10.17487 / RFC6206、2011年3月、<http:// www.rfc-editor.org/info/rfc6206>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, <http://www.rfc-editor.org/info/rfc6603>.
[RFC6603] Korhonen、J.、Ed。、Savolainen、T.、Krishnan、S.、and O. Troan、 "Prefix Exclude Option for DHCPv6-based Prefix Delegation"、RFC 6603、DOI 10.17487 / RFC6603、May 2012、< http://www.rfc-editor.org/info/rfc6603>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNS-Based Service Discovery」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<http://www.rfc-editor.org/info/rfc6763>。
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成(SLAAC)を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<http://www.rfc-editor.org / info / rfc7217>。
[RFC7695] Pfister, P., Paterson, B., and J. Arkko, "Distributed Prefix Assignment Algorithm", RFC 7695, DOI 10.17487/RFC7695, November 2015, <http://www.rfc-editor.org/info/rfc7695>.
[RFC7695] Pfister、P.、Paterson、B。、およびJ. Arkko、「分散プレフィックス割り当てアルゴリズム」、RFC 7695、DOI 10.17487 / RFC7695、2015年11月、<http://www.rfc-editor.org/info / rfc7695>。
[RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, <http://www.rfc-editor.org/info/rfc7787>.
[RFC7787] Stenberg、M。、およびS. Barth、「Distributed Node Consensus Protocol」、RFC 7787、DOI 10.17487 / RFC7787、2016年4月、<http://www.rfc-editor.org/info/rfc7787>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, <http://www.rfc-editor.org/info/rfc3118>.
[RFC3118] Droms、R.、Ed。 W. Arbaugh編、「DHCPメッセージの認証」、RFC 3118、DOI 10.17487 / RFC3118、2001年6月、<http://www.rfc-editor.org/info/rfc3118>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms(SHA and SHA-based HMAC and HKDF)」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<http://www.rfc- editor.org/info/rfc6234>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol(NETCONF)」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<http://www.rfc-editor.org/info/rfc6762>。
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルータの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<http:// www .rfc-editor.org / info / rfc7084>。
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, <http://www.rfc-editor.org/info/rfc7368>.
[RFC7368] Chown、T.、Ed。、Arkko、J.、Brandt、A.、Troan、O。、およびJ. Weil、「IPv6 Home Networking Architecture Principles」、RFC 7368、DOI 10.17487 / RFC7368、2014年10月、 <http://www.rfc-editor.org/info/rfc7368>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security(TLS)およびDatagram Transport Layer Security(DTLS)の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
Acknowledgments
謝辞
Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek, and Thomas Clausen for their contributions to the document.
ドキュメントへの貢献に対して、Ole Troan、Mark Baugher、Mark Townsley、Juliusz Chroboczek、およびThomas Clausenに感謝します。
Thanks to Eric Kline for the original border discovery work.
オリジナルの国境発見作業をしてくれたEric Klineに感謝します。
Authors' Addresses
著者のアドレス
Markus Stenberg Independent Helsinki 00930 Finland
Markus Stenberg独立ヘルシンキ00930フィンランド
Email: markus.stenberg@iki.fi
Steven Barth Independent Halle 06114 Germany
スティーブンバース独立ハレ06114ドイツ
Email: cyrus@openwrt.org
Pierre Pfister Cisco Systems Paris France
Pierre Pfister Cisco Systems Paris France
Email: pierre.pfister@darou.fr