RFC 7086 - Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7086
タイトル : RFC 7086 - ホストIDプロトコルベースのオーバーレイネットワーキング環境（HIP BONE）のインスタンス仕様で、リソースの検索と検出（RELOAD）を再利用
翻訳編集 : 自動生成

[要約] RFC 7086は、Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)に関する仕様です。このRFCの目的は、RELOADプロトコルを使用してリソースの場所と検索を行うためのHIP BONEインスタンスの仕様を提供することです。

Internet Engineering Task Force (IETF)                        A. Keranen
Request for Comments: 7086                                  G. Camarillo
Category: Experimental                                        J. Maenpaa
ISSN: 2070-1721                                                 Ericsson
                                                            January 2014

Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)

ホストIDプロトコルベースのオーバーレイネットワーキング環境（HIP BONE）のインスタンス仕様で、リソースの検索と検出（RELOAD）を再利用

Abstract

概要

This document is the HIP-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP.

このドキュメントは、REsource LOcation And Discovery（RELOAD）プロトコルのHIPベースのオーバーレイネットワーク環境（HIP BONE）インスタンス仕様です。このドキュメントは、HIPを使用するRELOADベースのオーバーレイを構築するために必要な詳細を提供します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7086.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7086で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Node ID Generation  . . . . . . . . . . . . . . . . . . . . .   3
   5.  Mapping between Protocol Primitives and HIP Messages  . . . .   3
     5.1.  Forwarding Header . . . . . . . . . . . . . . . . . . . .   4
     5.2.  Security Block  . . . . . . . . . . . . . . . . . . . . .   4
     5.3.  Replaced RELOAD Messages  . . . . . . . . . . . . . . . .   5
   6.  Securing Communication  . . . . . . . . . . . . . . . . . . .   5
   7.  Routing HIP Messages via the Overlay  . . . . . . . . . . . .   5
   8.  Enrollment and Bootstrapping  . . . . . . . . . . . . . . . .   6
   9.  NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . .   7
   10. RELOAD Overlay Configuration Document Extension . . . . . . .   7
   11. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     14.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     14.2.  Informative References . . . . . . . . . . . . . . . . .   9

1. Introduction

1. はじめに

The HIP-Based Overlay Networking Environment (HIP BONE) specification [RFC6079] provides a high-level framework for building HIP-based [RFC5201] overlays. The HIP BONE framework does not address the specification of the details on how to combine a particular peer protocol with HIP to build an overlay. It leaves this up to documents referred to as HIP BONE instance specifications. As discussed in [RFC6079], a HIP BONE instance specification needs to define, minimally: o the peer protocol to be used.

HIPベースのオーバーレイネットワーク環境（HIP BONE）仕様[RFC6079]は、HIPベースの[RFC5201]オーバーレイを構築するための高レベルのフレームワークを提供します。 HIP BONEフレームワークは、特定のピアプロトコルをHIPと組み合わせてオーバーレイを構築する方法の詳細の仕様には対応していません。これは、HIP BONEインスタンス仕様と呼ばれるドキュメントに任されています。 [RFC6079]で説明されているように、HIP BONEインスタンスの仕様では、最低限以下を定義する必要があります。o使用するピアプロトコル。

o what kind of Node IDs are used and how they are derived.

o 使用されるノードIDの種類とその導出方法。

o which peer protocol primitives trigger HIP messages.

o どのピアプロトコルプリミティブがHIPメッセージをトリガーするか。

o how the overlay identifier is generated.

o オーバーレイ識別子の生成方法。

This document addresses all the previous items and provides additional details needed to build RELOAD-based HIP BONEs, referred to here as RELOAD HIP BONEs. The details on how different RELOAD modules would be integrated to a HIP implementation and what kind of APIs are used between them are left as implementation details or to be defined by other documents.

このドキュメントでは、前述のすべての項目を取り上げ、RELOADベースのHIP BONEを構築するために必要な追加の詳細を提供します。ここでは、RELOAD HIP BONEと呼びます。異なるRELOADモジュールがHIP実装にどのように統合されるか、およびそれらの間でどのようなAPIが使用されるかの詳細は、実装の詳細として残されるか、他のドキュメントで定義されます。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In addition, this document uses the terms defined in [RFC5201], [RFC6079], [RFC6028], and [RFC6940].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。さらに、このドキュメントでは、[RFC5201]、[RFC6079]、[RFC6028]、および[RFC6940]で定義されている用語を使用しています。

3. Peer Protocol

3. ピアプロトコル

The peer protocol to be used is REsource LOcation And Discovery (RELOAD) [RFC6940]. When used with RELOAD, HIP replaces the RELOAD's Forwarding and Link Management Layer (described in Section 6.5 of [RFC6940]).

使用するピアプロトコルは、REsource LOcation And Discovery（RELOAD）[RFC6940]です。 RELOADと共に使用すると、HIPはRELOADの転送およびリンク管理レイヤーに置き換わります（[RFC6940]のセクション6.5で説明）。

4. Node ID Generation

4. ノードIDの生成

This document specifies two modes for generating Node and Resource IDs. Which mode is used in an actual overlay is defined by the overlay configuration. Both of the modes are based on 16-byte ID mode of RELOAD; hence, only 16-byte RELOAD Node and Resource IDs MUST be used in a RELOAD HIP BONE.

このドキュメントでは、ノードIDとリソースIDを生成するための2つのモードを指定します。実際のオーバーレイで使用されるモードは、オーバーレイ構成によって定義されます。どちらのモードも、RELOADの16バイトIDモードに基づいています。したがって、16バイトのRELOADノードとリソースIDのみをRELOAD HIP BONEで使用する必要があります。

HIP uses 128-bit Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843] as identifiers. In a RELOAD HIP BONE, a peer's ORCHID can be used as a RELOAD Node ID (the "ORCHID" mode). In this mode, all the RELOAD IDs, including Resource IDs, are prefixed with the ORCHID prefix, and the lower 100 bits of the IDs defined by RELOAD usage documents are used after the prefix.

HIPは、128ビットのオーバーレイルーティング可能な暗号化ハッシュ識別子（ORCHID）[RFC4843]を識別子として使用します。 RELOAD HIP BONEでは、ピアのORCHIDをRELOADノードIDとして使用できます（「ORCHID」モード）。このモードでは、リソースIDを含むすべてのRELOAD IDの前にORCHIDプレフィックスが付き、RELOAD使用法ドキュメントで定義されたIDの下位100ビットがプレフィックスの後に使用されます。

In the other Node ID mode, namely "RELOAD", all 128 bits are generated as defined in [RFC6940]. This results in a larger usable address space than using the ORCHID mode, but the resulting Node IDs cannot be used with legacy applications and APIs, as discussed in Section 5.1 of [RFC6079].

他のノードIDモード、つまり「RELOAD」では、[RFC6940]で定義されているように、128ビットすべてが生成されます。これにより、ORCHIDモードを使用する場合よりも使用可能なアドレススペースが大きくなりますが、[RFC6079]のセクション5.1で説明されているように、結果のノードIDをレガシーアプリケーションおよびAPIで使用することはできません。

5. Mapping between Protocol Primitives and HIP Messages

5. プロトコルプリミティブとHIPメッセージ間のマッピング

RELOAD HIP BONE replaces the RELOAD protocol primitives taking care of connection establishment with the HIP base exchange, whereas the rest of the RELOAD messages are conveyed within HIP messages. The Forwarding and Link Management Layer functionality of RELOAD, including all the NAT traversal functionality, is replaced by HIP, existing extensions of HIP, and the extensions defined in this document.

RELOAD HIP BONEは、接続の確立を処理するRELOADプロトコルプリミティブをHIPベース交換で置き換え、残りのRELOADメッセージはHIPメッセージ内で伝達されます。すべてのNATトラバーサル機能を含むRELOADの転送およびリンク管理レイヤー機能は、HIP、HIPの既存の拡張機能、およびこのドキュメントで定義されている拡張機能に置き換えられます。

The standard RELOAD messages consist of three parts: the forwarding header, the message contents, and the security block. When RELOAD messages are sent in a RELOAD HIP BONE overlay, the RELOAD message contents are used as such within HIP DATA [RFC6078] messages, but the functionality of the forwarding header and security block are replaced with the HIP header, HIP Destination and Via lists [RFC6028], CERT [RFC6253], TRANSACTION_ID [RFC6078], and the OVERLAY_ID and OVERLAY_TTL [RFC6079] parameters, as defined in the following sections.

標準のRELOADメッセージは、転送ヘッダー、メッセージの内容、セキュリティブロックの3つの部分で構成されています。 RELOADメッセージがRELOAD HIP BONEオーバーレイで送信される場合、RELOADメッセージの内容はHIP DATA [RFC6078]メッセージ内でそのまま使用されますが、転送ヘッダーとセキュリティブロックの機能はHIPヘッダー、HIP宛先、およびViaリストに置き換えられます[RFC6028]、CERT [RFC6253]、TRANSACTION_ID [RFC6078]、およびOVERLAY_IDおよびOVERLAY_TTL [RFC6079]パラメーター。以下のセクションで定義されています。

5.1. Forwarding Header

5.1. 転送ヘッダー

The RELOAD forwarding header is used for forwarding messages between peers and to their final destination. The forwarding header's overlay field value MUST be used as such in an OVERLAY_ID parameter and the transaction_id field in a TRANSACTION_ID parameter. That is, all RELOAD HIP BONE messages MUST contain these parameters; and, the length of the OVERLAY_ID parameter's identifier field is 4, and the length of the TRANSACTION_ID parameter is 8 octets. HIP Destination and Via lists are used for the same purpose as the destination_list and via_list in the forwarding header, with the exception that all Resource IDs MUST be of the same length as Node IDs, and compressed IDs MUST NOT be used. The Time to Live (TTL) value in the OVERLAY_TTL parameter is used like the ttl field in the forwarding header.

RELOAD転送ヘッダーは、ピア間およびその最終宛先へのメッセージの転送に使用されます。転送ヘッダーのオーバーレイフィールド値は、OVERLAY_IDパラメータやTRANSACTION_IDパラメータのtransaction_idフィールドでそのまま使用する必要があります。つまり、すべてのRELOAD HIP BONEメッセージにはこれらのパラメーターが含まれている必要があります。また、OVERLAY_IDパラメータの識別子フィールドの長さは4で、TRANSACTION_IDパラメータの長さは8オクテットです。 HIP宛先リストおよびViaリストは、転送ヘッダーのdestination_listおよびvia_listと同じ目的で使用されますが、すべてのリソースIDはノードIDと同じ長さでなければならず、圧縮されたIDは使用してはなりません。 OVERLAY_TTLパラメータのTime to Live（TTL）値は、転送ヘッダーのttlフィールドのように使用されます。

The functionality of the fragment and length fields are provided by the HIP headers. The relo_token, version, and max_response_length are not needed with HIP. The forwarding header's options field, if needed eventually for some extensions, can be substituted with additional HIP parameters.

フラグメントおよび長さフィールドの機能は、HIPヘッダーによって提供されます。 relo_token、version、max_response_lengthはHIPでは必要ありません。転送ヘッダーのオプションフィールドは、最終的に一部の拡張機能で必要になる場合、追加のHIPパラメータで置き換えることができます。

5.2. Security Block

5.2. セキュリティブロック

The RELOAD security block contains certificates and digital signatures of the message. All the HIP DATA messages are digitally signed by the originator of the message and contain the HOST_ID parameter with the identifier that can be used for verifying the signature. Certificates are delivered in a HIP CERT parameter as defined in [RFC6253] or stored to the overlay using the RELOAD Certificate Storage Usage.

RELOADセキュリティブロックには、メッセージの証明書とデジタル署名が含まれています。すべてのHIP DATAメッセージは、メッセージの発信者によってデジタル署名されており、署名の検証に使用できる識別子を持つHOST_IDパラメータが含まれています。証明書は、[RFC6253]で定義されているHIP CERTパラメータで配信されるか、RELOAD Certificate Storage Usageを使用してオーバーレイに保存されます。

Note that when the RELOAD mode for Node ID generation is used, the certificate certifying that a host is allowed to use a certain Node ID MUST contain the host's Node ID instead of the Host Identity Tag (HIT) in the "subjectAltName" field of the certificate as described in Section 11.3 of [RFC6940], while the "Subject" field contains the HIT calculated from the Host Identity.

ノードID生成にRELOADモードを使用する場合、ホストが特定のノードIDの使用を許可されていることを証明する証明書には、ホストIDタグ（HIT）ではなく、ホストのノードIDが「subjectAltName」フィールドに含まれている必要があります。 [RFC6940]のセクション11.3で説明されている証明書。「サブジェクト」フィールドには、ホストIDから計算されたHITが含まれます。

5.3. Replaced RELOAD Messages

5.3. 置き換えられたRELOADメッセージ

The Attach procedure in RELOAD establishes a connection between two peers. This procedure is performed using the AttachReq and AttachAns messages. When HIP is used, the Attach procedure is performed by using a HIP base exchange. That is, peers send HIP first Initiator (I1) messages instead of RELOAD AttachReq messages. This behavior replaces the one described in Section 6.5 of [RFC6940].

RELOADのAttachプロシージャは、2つのピア間の接続を確立します。この手順は、AttachReqおよびAttachAnsメッセージを使用して実行されます。 HIPを使用する場合、アタッチ手順はHIPベース交換を使用して実行されます。つまり、ピアはRELOAD AttachReqメッセージではなく、HIPファーストイニシエーター（I1）メッセージを送信します。この動作は、[RFC6940]のセクション6.5で説明されている動作に代わるものです。

The AppAttach procedure in RELOAD is used for creating a connection for other applications than RELOAD. Also, the AppAttach procedure is replaced with the HIP base exchange, and after the base exchange, peers can exchange any application layer data using the normal transport layer ports over the NAT traversing IPsec connection.

RELOADのAppAttachプロシージャは、RELOAD以外のアプリケーションの接続を作成するために使用されます。また、AppAttachプロシージャはHIPベース交換に置き換えられ、ベース交換後、ピアは、NATトラバースIPsec接続を介して通常のトランスポート層ポートを使用してアプリケーション層データを交換できます。

This specification does not support flooding of configuration files, so ConfigUpdate requests and responses (Section 6.5.4 of [RFC6940]) MUST NOT be sent in the overlay. RELOAD Ping messages (Section 6.5.3 of [RFC6940]) MAY be used.

この仕様は構成ファイルのフラッディングをサポートしていないため、ConfigUpdateリクエストとレスポンス（[RFC6940]のセクション6.5.4）をオーバーレイで送信してはなりません。 RELOAD Pingメッセージ（[RFC6940]のセクション6.5.3）を使用できます。

For all other RELOAD messages, the message contents are used as such within HIP DATA messages.

他のすべてのRELOADメッセージの場合、メッセージの内容はHIP DATAメッセージ内でそのまま使用されます。

6. Securing Communication

6. コミュニケーションの保護

RELOAD uses Transport Layer Security (TLS) [RFC5246] connections for securing the hop-by-hop messaging and certificates and signatures for providing integrity protection for the overlay messages and for the data stored in the overlay.

RELOADは、トランスポート層セキュリティ（TLS）[RFC5246]接続を使用して、ホップバイホップのメッセージングと証明書および署名を保護し、オーバーレイメッセージとオーバーレイに格納されているデータの整合性保護を提供します。

With a RELOAD HIP BONE, instead of using TLS connections as defined in [RFC6940], all HIP overlay messages MUST be sent using encrypted connections [RFC6261].

[RFC6940]で定義されているTLS接続を使用する代わりに、RELOAD HIP BONEを使用すると、すべてのHIPオーバーレイメッセージは暗号化接続[RFC6261]を使用して送信する必要があります。

The data objects stored in the RELOAD HIP BONE overlay are signed, and the signatures are stored as defined in [RFC6940] with the exception that SignerIdentity is carried in the HIP DATA message's HOST_ID parameter instead of using the RELOAD security block. Where certificates are needed, they are sent using the HIP CERT parameter.

RELOAD HIP BONEオーバーレイに格納されているデータオブジェクトは署名されており、署名は[RFC6940]で定義されているように格納されています。証明書が必要な場合は、HIP CERTパラメータを使用して送信されます。

7. Routing HIP Messages via the Overlay

7. オーバーレイを介したHIPメッセージのルーティング

If a host has no valid locator for the receiver of a new HIP packet, and the receiver is part of a RELOAD HIP BONE overlay the host is participating in, the host can send the HIP packet to the receiver using the overlay routing.

ホストに新しいHIPパケットのレシーバーの有効なロケーターがなく、レシーバーがホストが参加しているRELOAD HIP BONEオーバーレイの一部である場合、ホストはオーバーレイルーティングを使用してHIPパケットをレシーバーに送信できます。

When sending a HIP packet via the overlay, the host MUST add an empty ROUTE_VIA parameter [RFC6028] to the packet with the SYMMETRIC and MUST_FOLLOW flags set and an OVERLAY_ID parameter containing the identifier of the right overlay network. The host consults the RELOAD Topology Plugin for the next hop and sends the HIP packet to that host.

オーバーレイを介してHIPパケットを送信する場合、ホストは、SYMMETRICおよびMUST_FOLLOWフラグが設定されたパケットにROUTE_VIAパラメータ[RFC6028]を追加し、正しいオーバーレイネットワークの識別子を含むOVERLAY_IDパラメータを追加する必要があります。ホストは、ネクストホップのRELOADトポロジプラグインを参照し、HIPパケットをそのホストに送信します。

An intermediate host receiving a HIP packet with the OVERLAY_ID parameter checks if it is participating in that overlay and SHOULD drop packets sent to unknown overlays. If the host is not the final destination of the packet (i.e., the Receiver HIT in the HIP header does not match to any of its HITs), it checks if the packet contains a ROUTE_DST parameter. Such packets are forwarded to the next hop as specified in [RFC6028]. If the packet does not contain a ROUTE_DST parameter, the host finds the next hop from the RELOAD Topology Plugin and forwards the packet there. As specified in [RFC6028], the host adds the HIT it uses on the HIP association with the next-hop host to the end of the ROUTE_VIA parameter, if present.

OVERLAY_IDパラメーターを使用してHIPパケットを受信する中間ホストは、そのオーバーレイに参加しているかどうかを確認し、不明なオーバーレイに送信されたパケットをドロップする必要があります（SHOULD）。ホストがパケットの最終宛先でない場合（つまり、HIPヘッダーのレシーバーHITがそのHITのいずれとも一致しない場合）、ホストはパケットにROUTE_DSTパラメーターが含まれているかどうかを確認します。このようなパケットは、[RFC6028]で指定されているネクストホップに転送されます。パケットにROUTE_DSTパラメータが含まれていない場合、ホストはRELOADトポロジプラグインから次のホップを見つけて、そこにパケットを転送します。 [RFC6028]で指定されているように、ホストは、ネクストホップホストとのHIPアソシエーションで使用するHITをROUTE_VIAパラメータの最後に追加します（存在する場合）。

When the final destination host receives the HIP packet, the host processes it as specified in [RFC5201]; and, if the packet is a HIP DATA packet, the contents are processed as specified in [RFC6940]. If the HIP packet generates a response, the response is routed back on the same path using the ROUTE_DST parameter as specified in [RFC6028].

最終宛先ホストがHIPパケットを受信すると、ホストはそれを[RFC5201]で指定されているように処理します。そして、パケットがHIP DATAパケットであるならば、内容は[RFC6940]で指定されるように処理されます。 HIPパケットが応答を生成する場合、その応答は[RFC6028]で指定されているROUTE_DSTパラメータを使用して同じパスにルーティングされます。

8. Enrollment and Bootstrapping

8. 登録とブートストラップ

The RELOAD HIP BONE instance uses the enrollment and bootstrap procedure defined by RELOAD [RFC6940] with the exceptions listed below.

RELOAD HIP BONEインスタンスは、RELOAD [RFC6940]で定義されている登録およびブートストラップ手順を使用しますが、以下の例外があります。

o In RELOAD, a node wishing to enroll in an overlay starts with obtaining a configuration document as explained in [RFC6940]. This specification extends the RELOAD overlay configuration document as defined in Section 10.

o RELOADでは、オーバーレイに登録するノードは、[RFC6940]で説明されているように、構成ドキュメントを取得することから始まります。この仕様は、セクション10で定義されているRELOADオーバーレイ構成文書を拡張したものです。

o The X.509 certificates used by the RELOAD HIP BONE instance are similar to those of RELOAD except that they contain HITs instead of RELOAD URIs. The HITs are included in the SubjectAltName field of the certificate as described in [RFC6253].

o RELOAD HIP BONEインスタンスで使用されるX.509証明書は、RELOAD URIの代わりにHITが含まれていることを除いて、RELOADの証明書と似ています。 [RFC6253]で説明されているように、HITは証明書のSubjectAltNameフィールドに含まれています。

o When contacting a bootstrap node, instead of forming a Datagram Transport Layer Security (DTLS) or TLS connection, the host MUST perform a HIP base exchange with the bootstrap node. The base exchange MAY be performed using a HIP rendezvous or relay server.

o データグラムトランスポート層セキュリティ（DTLS）またはTLS接続を形成する代わりに、ブートストラップノードに接続する場合、ホストはブートストラップノードとのHIPベース交換を実行する必要があります。基本交換は、HIPランデブーサーバーまたはリレーサーバーを使用して実行される場合があります。

9. NAT Traversal

9. NATトラバーサル

RELOAD relies on the Forwarding and Link Management Layer providing NAT traversal capabilities. Thus, the RELOAD HIP BONE instance implementations MUST implement some reliable NAT traversal mechanism. To maximize interoperability, all implementations SHOULD implement at least [RFC5770].

RELOADは、NATトラバーサル機能を提供する転送およびリンク管理レイヤーに依存しています。したがって、RELOAD HIP BONEインスタンスの実装は、信頼できるNATトラバーサルメカニズムを実装する必要があります。相互運用性を最大にするために、すべての実装は少なくとも[RFC5770]を実装する必要があります。

HIP relay servers are not necessarily needed with this HIP BONE instance since the overlay network can be used for relaying the base exchange, and further HIP signaling can be done directly between the peers. However, if it is possible that a bootstrap peer is behind a NAT, it MUST register with a HIP relay so that there is a reliable way to connect to it.

このHIP BONEインスタンスではHIPリレーサーバーは必ずしも必要ではありません。オーバーレイネットワークはベース交換のリレーに使用でき、さらにピア間で直接HIPシグナリングを行うことができるためです。ただし、ブートストラップピアがNATの背後にある可能性がある場合は、信頼できる方法で接続できるように、HIPリレーに登録する必要があります。

10. RELOAD Overlay Configuration Document Extension

10. RELOADオーバーレイ構成文書拡張

This document modifies the bootstrap-node element of the RELOAD overlay configuration document. The modified bootstrap-node element contains the following attributes:

このドキュメントは、RELOADオーバーレイ設定ドキュメントのbootstrap-node要素を変更します。変更されたbootstrap-node要素には、次の属性が含まれています。

address: The locator of the bootstrap node.

address：ブートストラップノードのロケーター。

port: The HIP port of the bootstrap node.

port：ブートストラップノードのHIPポート。

hit: The HIT of the bootstrap node.

hit：ブートストラップノードのHIT。

If the bootstrap-node element does not contain a HIT, the opportunistic mode (as specified in [RFC5201]) SHOULD be used for contacting the bootstrap node. If the element does not contain a port number, the bootstrap node SHOULD be contacted by starting the base exchange as defined in [RFC5201]. Otherwise, the base exchange MUST be started with UDP encapsulation, as defined in [RFC5770], using the given port as the destination port number.

bootstrap-node要素にHITが含まれていない場合、（[RFC5201]で指定されている）日和見モードを使用して、ブートストラップノードに接続する必要があります（SHOULD）。要素にポート番号が含まれていない場合は、[RFC5201]で定義されているように基本交換を開始することにより、ブートストラップノードに接続する必要があります（SHOULD）。それ以外の場合、[RFC5770]で定義されているように、指定されたポートを宛先ポート番号として使用して、ベース交換をUDPカプセル化で開始する必要があります。

A RELOAD HIP BONE overlay MUST use the Overlay Link Protocol type "HIP" in the configuration document's overlay-link-protocol element. The enrolling node MUST check the overlay-link-protocol element and proceed with procedures defined in this document only if the "HIP" link type is found.

RELOAD HIP BONEオーバーレイは、構成ドキュメントのoverlay-link-protocol要素でオーバーレイリンクプロトコルタイプ「HIP」を使用する必要があります。登録ノードはoverlay-link-protocol要素をチェックし、「HIP」リンクタイプが見つかった場合にのみ、このドキュメントで定義されている手順を実行する必要があります。

This document also adds a new element inside the configuration element that defines which mode (see Section 4) is used for generating the Node and Resource IDs. The name of the element is "hipbone-id-mode" and the content is the identifier of the mode: "ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that use the whole 128 bits as defined by the RELOAD specification. The NodeIdLength MUST be set to 16 in the configuration document, and the 16 bytes are used, depending on the generation mode, as defined in Section 4.

このドキュメントでは、ノードIDとリソースIDの生成に使用するモード（セクション4を参照）を定義する構成要素内に新しい要素も追加しています。要素の名前は「hipbone-id-mode」で、コンテンツはモードの識別子です。ORCHIDプレフィックスIDの場合は「ORCHID」、RELOAD仕様で定義されている128ビット全体を使用するIDの場合は「RELOAD」。 NodeIdLengthは構成ドキュメントで16に設定する必要があり、セクション4で定義されているように、生成モードに応じて16バイトが使用されます。

11. Security Considerations

11. セキュリティに関する考慮事項

The security considerations of RELOAD (Section 13 of [RFC6940]), with the exception of TLS-specific features, also apply to RELOAD HIP BONE instances.

RELOADのセキュリティに関する考慮事項（[RFC6940]のセクション13）は、TLS固有の機能を除いて、RELOAD HIP BONEインスタンスにも適用されます。

Limiting the Node ID and Resource ID space into 128 bits (or 100 bits with ORCHID prefixes) results in a higher probability for ID collisions, both unintentional and intentional, than using larger address spaces.

ノードIDとリソースIDスペースを128ビット（またはORCHIDプレフィックス付きの100ビット）に制限すると、より大きなアドレススペースを使用するよりも、意図的でない意図的なID衝突の可能性が高くなります。

12. IANA Considerations

12. IANAに関する考慮事項

This section is to be interpreted according to [RFC5226].

このセクションは、[RFC5226]に従って解釈されます。

IANA has updated the "RELOAD Overlay Link Protocol Registry" [RFC6940] by assigning the new Overlay Link Protocol type "HIP" (see Section 10).

IANAは、「RELOADオーバーレイリンクプロトコルレジストリ」[RFC6940]を更新し、新しいオーバーレイリンクプロトコルタイプ「HIP」を割り当てました（セクション10を参照）。

13. Acknowledgements

13. 謝辞

Tom Henderson, Spencer Dawkins, and Christer Holmberg have provided valuable reviews and comments on the document.

Tom Henderson、Spencer Dawkins、およびChrister Holmbergは、このドキュメントに関する貴重なレビューとコメントを提供しています。

14. References

14. 参考文献

14.1. Normative References

14.1. 引用文献

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

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

[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.

[RFC4843] Nikander、P.、Laganier、J。、およびF. Dupont、「オーバーレイ可能なルーティング可能な暗号化ハッシュ識別子（ORCHID）のIPv6プレフィックス」、RFC 4843、2007年4月。

[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.

[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。

[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.

[RFC5770] Komu、M.、Henderson、T.、Tschofenig、H.、Melen、J。、およびA. Keranen、「Basic Host Identity Protocol（HIP）Extensions for Traversal of Network Address Translators」、RFC 5770、2010年4月。

[RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol (HIP) Multi-Hop Routing Extension", RFC 6028, October 2010.

[RFC6028] Camarillo、G。およびA. Keranen、「ホストIDプロトコル（HIP）マルチホップルーティング拡張機能」、RFC 6028、2010年10月。

[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011.

[RFC6078] Camarillo、G.およびJ. Melen、「Host Identity Protocol（HIP）Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling（HICCUPS）」、RFC 6078、2011年1月。

[RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)", RFC 6079, January 2011.

[RFC6079]カマリロ、G。、ニカンダー、P。、ハウタコルピ、J。、ケラネン、A。、およびA.ジョンストン、「HIP BONE：Host Identity Protocol（HIP）Based Overlay Networking Environment（BONE）」、RFC 6079、 2011年1月。

[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.

[RFC6253] Heer、T。およびS. Varjonen、「Host Identity Protocol Certificates」、RFC 6253、2011年5月。

[RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the Host Identity Protocol", RFC 6261, May 2011.

[RFC6261] Keranen、A。、「Host Identity Protocolの暗号化されたシグナリングトランスポートモード」、RFC 6261、2011年5月。

[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", January 2014.

[RFC6940] Jennings、C.、Lowekamp、B.、Rescorla、E.、Baset、S。、およびH. Schulzrinne、「REsource LOcation And Discovery（RELOAD）Base Protocol」、2014年1月。

14.2. Informative References

14.2. 参考引用

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。

Authors' Addresses

著者のアドレス

Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland

ありけらねんえりｃっそんひｒさぁんちえ１１０２４２０じょｒゔぁｓふぃんぁんｄ

   EMail: Ari.Keranen@ericsson.com

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420 Finland

Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420フィンランド

   EMail: Jouni.Maenpaa@ericsson.com