[要約] RFC 8047は、ホストアイデンティティプロトコル（HIP）を使用したホストのマルチホーミングに関する要約です。このRFCの目的は、HIPを使用してホストが複数のネットワークインターフェースを持つ場合に、ホストのアドレスの管理と通信の効率を向上させることです。
Internet Engineering Task Force (IETF) T. Henderson, Ed.
Request for Comments: 8047 University of Washington
Category: Standards Track C. Vogt
ISSN: 2070-1721 Independent
J. Arkko
Ericsson
February 2017
Host Multihoming with the Host Identity Protocol
ホストIDプロトコルを使用したホストマルチホーミング
Abstract
概要
This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.
このドキュメントでは、ホストモビリティ用に定義されたプロトコルコンポーネントを利用して、ホストアイデンティティプロトコル（HIP）のホストマルチホーミング拡張機能を定義します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8047.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8047で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 and Scope . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Multiple Addresses . . . . . . . . . . . . . . . . . 6
4.2.2. Multiple Security Associations . . . . . . . . . . . 6
4.2.3. Host Multihoming for Fault Tolerance . . . . . . . . 7
4.2.4. Host Multihoming for Load Balancing . . . . . . . . . 9
4.2.5. Site Multihoming . . . . . . . . . . . . . . . . . . 10
4.2.6. Dual-Host Multihoming . . . . . . . . . . . . . . . . 10
4.2.7. Combined Mobility and Multihoming . . . . . . . . . . 11
4.2.8. Initiating the Protocol in R1, I2, or R2 . . . . . . 11
4.2.9. Using LOCATOR_SETs across Addressing Realms . . . . . 13
4.3. Interaction with Security Associations . . . . . . . . . 13
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 14
5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 16
5.3. Verifying Address Reachability . . . . . . . . . . . . . 18
5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The Host Identity Protocol (HIP) [RFC7401] supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities. When a host uses HIP, the overlying protocol sublayers (e.g., transport-layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) are instead bound to representations of these host identities, and the IP addresses are only used for packet forwarding. However, each host must also know at least one IP address at which its peers are reachable. Initially, these IP addresses are the ones used during the HIP base exchange.
Host Identity Protocol（HIP）[RFC7401]は、IPアドレスの代わりに公開/秘密鍵のペアをホストとして使用することにより、トランスポート層（TCP、UDPなど）をインターネットワーキング層（IPv4およびIPv6）から切り離すアーキテクチャをサポートしますアイデンティティ。ホストがHIPを使用する場合、上位のプロトコルサブレイヤー（トランスポートレイヤーソケットやカプセル化セキュリティペイロード（ESP）セキュリティアソシエーション（SA）など）は、これらのホストIDの表現にバインドされ、IPアドレスはパケット転送にのみ使用されます。ただし、各ホストは、そのピアが到達可能な少なくとも1つのIPアドレスも知っている必要があります。最初は、これらのIPアドレスはHIPベース交換中に使用されるものです。
One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. Basic host mobility is defined in [RFC8046] and covers the case in which a host has a single address and changes its network point of attachment while desiring to preserve the HIP-enabled security association. Host multihoming is somewhat of a dual case to host mobility, in that, a host may simultaneously have more than one network point of attachment. There are potentially many variations of host multihoming possible. [RFC8046] specifies the format of the HIP parameter (LOCATOR_SET parameter) used to convey IP addressing information between peers, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for an address verification mechanism. The scope of this document encompasses messaging and elements of procedure for some basic host multihoming scenarios of interest.
このような分離の1つの結果は、ネットワーク層のモビリティとホストのマルチホーミングに対する新しいソリューションが可能になることです。基本的なホストモビリティは[RFC8046]で定義されており、ホストが単一のアドレスを持ち、ネットワーク接続ポイントを変更する一方で、HIP対応のセキュリティアソシエーションを維持したい場合に対応します。ホストのマルチホーミングは、ホストのモビリティにとって多少二重のケースです。つまり、ホストは同時に複数のネットワーク接続ポイントを持つことができます。ホストマルチホーミングには、多くのバリエーションが考えられます。 [RFC8046]は、ピア間でIPアドレッシング情報を伝達するために使用されるHIPパラメータ（LOCATOR_SETパラメータ）のフォーマット、このパラメータを送信および処理して基本的なホストモビリティを有効にする手順、およびアドレス検証メカニズムの手順を指定します。このドキュメントの範囲には、関心のあるいくつかの基本的なホストマルチホーミングシナリオのメッセージングと手順の要素が含まれます。
Another variation of multihoming that has been heavily studied is site multihoming. Solutions for host multihoming in multihomed IPv6 networks have been specified by the IETF shim6 working group. The Shim6 protocol [RFC5533] bears many architectural similarities to HIP, but there are differences in the security model and in the protocol.
よく研究されているマルチホーミングのもう1つのバリエーションは、サイトマルチホーミングです。マルチホームIPv6ネットワークでのホストマルチホーミングのソリューションは、IETF shim6ワーキンググループによって指定されています。 Shim6プロトコル[RFC5533]は、HIPと多くのアーキテクチャ上の類似点がありますが、セキュリティモデルとプロトコルには違いがあります。
While HIP can potentially be used with transports other than the ESP transport format [RFC7402], this document largely assumes the use of ESP and leaves other transport formats for further study.
HIPはESPトランスポートフォーマット[RFC7402]以外のトランスポートで使用できる可能性がありますが、このドキュメントでは主にESPの使用を想定しており、他のトランスポートフォーマットは今後の研究に残します。
Finally, making underlying IP multihoming transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the proper transport response to a HIP multihoming address change, are outside the scope of this document.
最後に、基になるIPマルチホーミングをトランスポート層に対して透過的にすることは、トランスポート輻輳制御、パスMTU選択、およびサービス品質（QoS）の適切な応答に影響します。トランスポート層のモビリティトリガー、およびHIPマルチホーミングアドレス変更に対する適切なトランスポート応答は、このドキュメントの範囲外です。
This specification relies on implementing Sections 4 ("LOCATOR_SET Parameter Format") and 5 ("Processing Rules") of [RFC8046] as a starting point for this implementation.
この仕様は、この実装の開始点として、[RFC8046]のセクション4（ "LOCATOR_SETパラメータ形式"）および5（ "処理規則"）の実装に依存しています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The following terms used in this document are defined in [RFC8046]: LOCATOR_SET, Locator, locator, Address, preferred locator, and Credit-Based Authorization.
このドキュメントで使用される次の用語は、[RFC8046]で定義されています：LOCATOR_SET、ロケーター、ロケーター、住所、優先ロケーター、およびクレジットベースの承認。
The protocol model for HIP support of host multihoming extends the model for host mobility described in Section 3 of [RFC8046]. This section only highlights the differences.
ホストマルチホーミングのHIPサポートのプロトコルモデルは、[RFC8046]のセクション3で説明されているホストモビリティのモデルを拡張します。このセクションでは、違いのみを取り上げます。
In host multihoming, a host has multiple locators simultaneously rather than sequentially, as in the case of mobility. By using the LOCATOR_SET parameter defined in [RFC8046], a host can inform its peers of additional (multiple) locators at which it can be reached. When multiple locators are available and announced to the peer, a host can designate a particular locator as a "preferred" locator, meaning that the host prefers that its peer send packets to the designated address before trying an alternative address. Although this document defines a basic mechanism for multihoming, it does not define all possible policies and procedures, such as which locators to choose when more than one is available, the operation of simultaneous mobility and multihoming, source address selection policies (beyond those specified in [RFC6724]), and the implications of multihoming on transport protocols.
ホストマルチホーミングでは、モビリティの場合のように、ホストは複数のロケーターを順次ではなく同時に持っています。 [RFC8046]で定義されているLOCATOR_SETパラメータを使用することにより、ホストは到達可能な追加の（複数の）ロケータをピアに通知できます。複数のロケータが利用可能でピアにアナウンスされる場合、ホストは特定のロケータを「優先」ロケータとして指定できます。つまり、ホストは、ピアが代替アドレスを試す前に指定されたアドレスにパケットを送信することを優先します。このドキュメントでは、マルチホーミングの基本的なメカニズムを定義していますが、複数のロケータが利用可能な場合に選択するロケータ、同時モビリティとマルチホーミングの操作、送信元アドレス選択ポリシー（ [RFC6724]）、およびトランスポートプロトコルに対するマルチホーミングの影響。
In this section, we briefly introduce a number of usage scenarios for HIP multihoming. These scenarios assume that HIP is being used with the ESP transport [RFC7402], although other scenarios may be defined in the future. To understand these usage scenarios, the reader should be at least minimally familiar with the HIP protocol specification [RFC7401], the use of the ESP transport format [RFC7402], and the HIP mobility specification [RFC8046]. However, for the (relatively) uninitiated reader, it is most important to keep in mind that in HIP, the actual payload traffic is protected with ESP, and that the ESP Security Parameter Index (SPI) acts as an index to the right host-to-host context.
このセクションでは、HIPマルチホーミングのいくつかの使用シナリオを簡単に紹介します。これらのシナリオは、ESPトランスポート[RFC7402]でHIPが使用されていることを前提としていますが、将来的には他のシナリオも定義される可能性があります。これらの使用シナリオを理解するには、読者は少なくともHIPプロトコル仕様[RFC7401]、ESPトランスポートフォーマット[RFC7402]の使用、およびHIPモビリティ仕様[RFC8046]に精通している必要があります。ただし、（比較的）未開始のリーダーの場合、HIPでは実際のペイロードトラフィックがESPで保護され、ESPセキュリティパラメータインデックス（SPI）が適切なホストへのインデックスとして機能することを覚えておくことが最も重要です。ホストへのコンテキスト。
The multihoming scenarios can be explained in contrast to the non-multihoming case described in the base protocol specification [RFC7401]. We review the pertinent details here. In the base specification, when used with the ESP transport format, the HIP base exchange will set up a single SA in each direction. The IP addresses associated with the SAs are the same as those used to convey the HIP packets. For data traffic, a security policy database (SPD) and security association database (SAD) will likely exist, following the IPsec architecture. One distinction between HIP and IPsec, however, is that the host IDs, and not the IP addresses, are conceptually used as selectors in the SPD. In the outbound direction, as a result of SPD processing, when an outbound SA is selected, the correct IP destination address for the peer must also be assigned. Therefore, outbound SAs are conceptually associated with the peer IP address that must be used as the destination IP address below the HIP layer. In the inbound direction, the IP addresses may be used as selectors in the SAD to look up the SA, but they are not strictly required; the ESP SPI may be used alone. To summarize, in the non-multihoming case, there is only one source IP address, one destination IP address, one inbound SA, and one outbound SA.
マルチホーミングのシナリオは、基本プロトコル仕様[RFC7401]で説明されている非マルチホーミングの場合とは対照的に説明できます。ここで関連する詳細を確認します。基本仕様では、ESPトランスポート形式で使用すると、HIPベース交換は各方向に単一のSAをセットアップします。 SAに関連付けられたIPアドレスは、HIPパケットの伝達に使用されるものと同じです。データトラフィックの場合、IPsecアーキテクチャに従って、セキュリティポリシーデータベース（SPD）とセキュリティアソシエーションデータベース（SAD）が存在する可能性があります。ただし、HIPとIPsecの違いの1つは、IPアドレスではなくホストIDが概念的にSPDのセレクターとして使用されることです。アウトバウンド方向では、SPD処理の結果として、アウトバウンドSAが選択されたときに、ピアの正しいIP宛先アドレスも割り当てる必要があります。したがって、アウトバウンドSAは、概念的にはHIPレイヤーの下の宛先IPアドレスとして使用する必要があるピアIPアドレスに関連付けられます。インバウンド方向では、SAを検索するためにIPアドレスをSADのセレクターとして使用できますが、これらは厳密に必須ではありません。 ESP SPIは単独で使用できます。要約すると、非マルチホーミングの場合、送信元IPアドレス、宛先IPアドレス、受信SA、送信SAはそれぞれ1つずつです。
The HIP readdressing protocol [RFC8046] is an asymmetric protocol in which a mobile or multihomed host informs a peer host about changes of IP addresses on affected SPIs. IP address and ESP SPI information is carried in Locator fields in a HIP parameter called a LOCATOR_SET. The HIP mobility specification [RFC8046] describes how the LOCATOR_SET is carried in a HIP UPDATE packet.
HIP再アドレス指定プロトコル[RFC8046]は、モバイルまたはマルチホームホストが影響を受けるSPIのIPアドレスの変更についてピアホストに通知する非対称プロトコルです。 IPアドレスとESP SPI情報は、LOCATOR_SETと呼ばれるHIPパラメータのロケータフィールドで伝達されます。 HIPモビリティ仕様[RFC8046]では、LOCATOR_SETがHIP UPDATEパケットでどのように伝送されるかについて説明しています。
To summarize the mobility elements of procedure, as background for multihoming, the basic idea of host mobility is to communicate a local IP address change to the peer when active HIP-maintained SAs are in use. To do so, the IP address must be conveyed, any association between the IP address and an inbound SA (via the SPI index) may be conveyed, and protection against flooding attacks must be ensured. The association of an IP address with an SPI is performed by a Locator Type of "1", which is a concatenation of an ESP SPI with an IP address.
手順のモビリティ要素を要約すると、マルチホーミングの背景として、ホストモビリティの基本的な考え方は、アクティブなHIPメンテナンスSAが使用されているときにローカルIPアドレスの変更をピアに通信することです。そのためには、IPアドレスを伝達する必要があり、IPアドレスとインバウンドSAの間の関連付け（SPIインデックスを介して）を伝達でき、フラッディング攻撃に対する保護を確実にする必要があります。 IPアドレスとSPIの関連付けは、ロケータタイプ「1」によって実行されます。これは、ESP SPIとIPアドレスを連結したものです。
An address verification method is specified in [RFC8046]. It is expected that addresses learned in multihoming scenarios also are subject to the same verification rules. At times, the scenarios describe addresses as being in either an ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a host, newly learned addresses of the peer must be verified before put into active service, and addresses removed by the peer are put into a deprecated state. Under limited conditions described in [RFC8046], an UNVERIFIED address may be used.
アドレス検証方法は[RFC8046]で指定されています。マルチホーミングシナリオで学習されたアドレスにも同じ検証ルールが適用されることが予想されます。時々、シナリオはアドレスをACTIVE、VERIFIED、またはDEPRECATED状態のいずれかであると説明します。ホストの観点から、ピアの新しく学習されたアドレスはアクティブサービスに入る前に確認する必要があり、ピアによって削除されたアドレスは非推奨の状態になります。 [RFC8046]で説明されている限られた条件下では、未確認のアドレスが使用される場合があります。
With this background, we next describe an additional protocol to facilitate scenarios in which one or both hosts have multiple IP addresses available. Increasingly, this is the common case with network-connected hosts on the Internet.
このような背景から、次に、1つまたは両方のホストが複数のIPアドレスを使用できるシナリオを容易にするための追加のプロトコルについて説明します。これはますます、インターネット上のネットワーク接続されたホストの一般的なケースです。
Hosts may have multiple IP addresses within different address families (IPv4 and IPv6) and scopes available to support HIP messaging and HIP-enabled SAs. The multiple addresses may be on a single network interface or multiple network interfaces. It is outside of the scope of this document to specify how a host decides which of possibly multiple addresses may be used to support a HIP association. Some IP addresses may be held back from usage due to privacy, security, or cost considerations.
ホストには、異なるアドレスファミリ（IPv4およびIPv6）内の複数のIPアドレスと、HIPメッセージングおよびHIP対応SAをサポートするために利用可能なスコープがある場合があります。複数のアドレスは、単一のネットワークインターフェイスまたは複数のネットワークインターフェイス上にある場合があります。 HIPアソシエーションをサポートするために使用される可能性のある複数のアドレスのどれをホストが決定するかを指定することは、このドキュメントの範囲外です。一部のIPアドレスは、プライバシー、セキュリティ、またはコストを考慮して、使用を控えられる場合があります。
When multiple IP addresses are shared with a peer, the procedures described in the HIP mobility specification [RFC8046] allow for a host to set a preferred locator ("P") bit, requesting that one of the multiple addresses be preferred for control- or data-plane traffic. It is also permitted to leave the preferred bit unset for all addresses, allowing the peer to make address selection decisions.
複数のIPアドレスがピアと共有されている場合、HIPモビリティ仕様[RFC8046]で説明されている手順により、ホストは優先ロケータ（ "P"）ビットを設定し、複数のアドレスの1つを制御またはデータプレーントラフィック。また、すべてのアドレスの優先ビットを未設定のままにして、ピアがアドレス選択を決定できるようにすることもできます。
Hosts that use link-local addresses as source addresses in their HIP handshakes may not be reachable by a mobile peer. Such hosts SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR_SET parameter.
リンクローカルアドレスをHIPハンドシェイクのソースアドレスとして使用するホストは、モバイルピアから到達できない場合があります。このようなホストは、初期ハンドシェイクで、またはLOCATOR_SETパラメータを介して、グローバルにルーティング可能なアドレスを提供する必要があります（SHOULD）。
To support mobility, as described in the HIP mobility specification [RFC8046], the LOCATOR_SET may be sent in a HIP UPDATE packet. To support multihoming, the LOCATOR_SET may also be sent in R1, I2, or R2 packets defined in the HIP protocol specification [RFC7401]. The reason to consider sending LOCATOR_SET parameters in base exchange packets is to convey all usable addresses for fault-tolerance or load-balancing considerations.
HIPモビリティ仕様[RFC8046]で説明されているように、モビリティをサポートするには、LOCATOR_SETをHIP UPDATEパケットで送信できます。マルチホーミングをサポートするために、LOCATOR_SETは、HIPプロトコル仕様[RFC7401]で定義されているR1、I2、またはR2パケットで送信することもできます。基本交換パケットでLOCATOR_SETパラメータを送信することを検討する理由は、フォールトトレランスまたはロードバランシングを考慮して、使用可能なすべてのアドレスを伝えるためです。
When multiple addresses are available between peer hosts, a question that arises is whether to use one or multiple SAs. The intent of this specification is to support different use cases but to leave the policy decision to the hosts.
ピアホスト間で複数のアドレスを使用できる場合、1つまたは複数のSAを使用するかどうかが問題になります。この仕様の目的は、さまざまなユースケースをサポートすることですが、ポリシーの決定はホストに任せることです。
When one host has n addresses and the other host has m addresses, it is possible to set up as many as (n * m) SAs in each direction. In such a case, every combination of source and destination IP addresses would have a unique SA, and the possibility of the reordering of datagrams on each SA will be lessened (ESP SAs may have an anti-replay window [RFC4303] sensitive to reordering). However, the downside to creating a mesh of SAs is the signaling overhead required (for exchanging UPDATE messages conveying ESP_INFO parameters) and the state maintenance required in the SPD/SAD.
一方のホストにn個のアドレスがあり、もう一方のホストにm個のアドレスがある場合、各方向に（n * m）個のSAを設定できます。このような場合、送信元IPアドレスと宛先IPアドレスのすべての組み合わせに一意のSAがあり、各SAでのデータグラムの並べ替えの可能性が低くなります（ESP SAには、リプレイの影響を受けにくいアンチリプレイウィンドウ[RFC4303]がある場合があります）。 。ただし、SAのメッシュを作成することの欠点は、（ESP_INFOパラメーターを伝達するUPDATEメッセージを交換するために）必要なシグナリングオーバーヘッドと、SPD / SADで必要な状態の維持です。
For load balancing, when multiple paths are to be used in parallel, it may make sense to create different SAs for different paths. In this use case, while a full mesh of 2 * (n * m) SAs may not be required, it may be beneficial to create one SA pair per load-balanced path to avoid anti-replay window issues.
ロードバランシングでは、複数のパスを並行して使用する場合、パスごとに異なるSAを作成することが理にかなっています。この使用例では、2 *（n * m）SAのフルメッシュは必要ない場合がありますが、アンチリプレイウィンドウの問題を回避するために、負荷分散されたパスごとに1つのSAペアを作成すると効果的です。
For fault tolerance, it is more likely that a single SA and multiple IP addresses associated with that SA can be used, and the alternative addresses can be used only upon failure detection of the addresses in use. Techniques for path failure detection are outside the scope of this specification. An implementation may use ICMP interactions, reachability checks, or other means to detect the failure of a locator.
フォールトトレランスについては、単一のSAとそのSAに関連付けられた複数のIPアドレスを使用できる可能性が高く、代替アドレスは、使用中のアドレスの障害検出時にのみ使用できます。パス障害検出の手法は、この仕様の範囲外です。実装では、ICMPインタラクション、到達可能性チェック、またはその他の手段を使用して、ロケーターの障害を検出できます。
In summary, whether and how a host decides to leverage additional addresses in a load-balancing or fault-tolerant manner is outside the scope of the specification (although the academic literature on multipath TCP schedulers may provide guidance on how to design such a policy). However, in general, this document recommends that for fault tolerance, it is likely sufficient to use a single SA pair for all addresses, and for load balancing, to support a different SA pair for all active paths being balanced across.
要約すると、ホストがロードバランシングまたはフォールトトレラントな方法で追加のアドレスを利用するかどうか、およびどのように決定するかは、仕様の範囲外です（ただし、マルチパスTCPスケジューラに関する学術文献は、そのようなポリシーの設計方法に関するガイダンスを提供する場合があります） 。ただし、一般に、このドキュメントでは、フォールトトレランスのために、すべてのアドレスに対して単一のSAペアを使用し、ロードバランシングのために、すべてのアクティブパスが異なるSAペアをサポートすることで十分であると推奨しています。
A (mobile or stationary) host may have more than one interface or global address. The host may choose to notify the peer host of the additional interface or address by using the LOCATOR_SET parameter. The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet, or it may be conveyed, after the base exchange completes in an UPDATE packet.
（モバイルまたは固定）ホストは、複数のインターフェースまたはグローバルアドレスを持つ場合があります。ホストは、LOCATOR_SETパラメータを使用して、追加のインターフェースまたはアドレスをピアホストに通知することを選択できます。 LOCATOR_SETパラメータは、I2、R1、またはR2パケットに含めることができます。または、基本交換がUPDATEパケットで完了した後に、それを伝えることもできます。
When more than one locator is provided to the peer host, the host MAY indicate which locator is preferred (the locator on which the host prefers to receive traffic). By default, the address that a host uses in the base exchange is its preferred locator (for the address family and address scope in use during the base exchange) until indicated otherwise. It may be the case that the host does not express any preferred locators.
ピアホストに複数のロケーターが提供されている場合、ホストはどのロケーターが優先されるか（ホストがトラフィックの受信を優先するロケーター）を示す場合があります。デフォルトでは、ホストが基本交換で使用するアドレスは、特に記載がない限り、（基本交換中に使用されるアドレスファミリとアドレススコープの）優先ロケータです。ホストが好ましいロケーターをまったく表していない場合もあります。
In the multihoming case, the sender may also have multiple valid locators from which to source traffic. In practice, a HIP association in a multihoming configuration may have both a preferred peer locator and a preferred local locator. The host should try to use the peer's preferred locator unless policy or other circumstances prevent such usage. A preferred local locator may be overridden if source address selection rules on the destination address (peer's preferred locator) suggest the use of a different source address.
マルチホーミングの場合、送信者は、トラフィックのソースとなる有効なロケーターを複数持つこともできます。実際には、マルチホーミング構成のHIPアソシエーションには、優先ピアロケーターと優先ローカルロケーターの両方がある場合があります。ホストは、ポリシーまたは他の状況がそのような使用を妨げない限り、ピアの優先ロケーターを使用しようとする必要があります。宛先アドレス（ピアの優先ロケーター）のソースアドレス選択ルールが別のソースアドレスの使用を示唆している場合、優先ローカルロケーターが上書きされる可能性があります。
Although the protocol may allow for configurations in which there is an asymmetric number of SAs between the hosts (e.g., one host has two interfaces and two inbound SAs, while the peer has one interface and one inbound SA), it is suggested that inbound and outbound SAs be created pairwise between hosts. When an ESP_INFO arrives to rekey a particular outbound SA, the corresponding inbound SA should also be rekeyed at that time. Section 4.3 discusses the interaction between addresses and security associations in more detail.
プロトコルは、ホスト間にSAの数が非対称である構成を許可する場合があります（たとえば、1つのホストには2つのインターフェースと2つのインバウンドSAがあり、ピアには1つのインターフェースと1つのインバウンドSAがあります）。アウトバウンドSAは、ホスト間でペアで作成されます。 ESP_INFOが到着して特定の送信SAのキーを再生成する場合、対応する受信SAもそのときに再キー化する必要があります。セクション4.3では、アドレスとセキュリティアソシエーション間の相互作用について詳しく説明します。
Consider the case of two hosts, one single-homed and one multihomed. The multihomed host may decide to inform the single-homed host about its other address(es). It may choose to do so as follows.
シングルホームとマルチホームの2つのホストの場合を考えます。マルチホームホストは、シングルホームホストに他のアドレスを通知することを決定できます。次のように選択する場合があります。
If the multihomed host wishes to convey the additional address(es) for fault tolerance, it should include all of its addresses in Locator fields, indicating the Traffic Type, Locator Type, and whether the locator is a preferred locator. If it wishes to bind any particular address to an existing SPI, it may do so by using a Locator Type of "1" as specified in the HIP mobility specification [RFC8046]. It does not need to rekey the existing SA or request additional SAs at this time.
マルチホームホストがフォールトトレランスのために追加のアドレスを伝達する場合は、ロケーターフィールドにすべてのアドレスを含め、トラフィックタイプ、ロケータータイプ、およびロケーターが優先ロケーターであるかどうかを示す必要があります。特定のアドレスを既存のSPIにバインドする場合は、HIPモビリティ仕様[RFC8046]で指定されているロケータータイプ "1"を使用してバインドできます。現時点では、既存のSAのキーを再作成したり、追加のSAを要求したりする必要はありません。
Figure 1 illustrates this scenario. Note that the conventions for message parameter notations in figures (use of parentheses and brackets) is defined in Section 2.2 of [RFC7401].
図1は、このシナリオを示しています。図中のメッセージパラメータ表記の規則（括弧と括弧の使用）は、[RFC7401]のセクション2.2で定義されていることに注意してください。
Multihomed Host Peer Host
マルチホームホストピアホスト
UPDATE(LOCATOR_SET, SEQ)
----------------------------------->
UPDATE(ACK)
<-----------------------------------
Figure 1: Basic Multihoming Scenario
図1：基本的なマルチホーミングシナリオ
In this scenario, the peer host associates the multiple addresses with the SA pair between it and the multihomed host. It may also undergo address verification procedures to transition the addresses to ACTIVE state. For inbound data traffic, it may choose to use the addresses along with the SPI as selectors. For outbound data traffic, it must choose among the available addresses of the multihomed host, considering the state of address verification [RFC8046] of each address, and also considering available information about whether an address is in a working state.
このシナリオでは、ピアホストは、複数のアドレスをマルチホームホストとの間のSAペアに関連付けます。また、アドレス検証手順を実行して、アドレスをACTIVE状態に遷移させることもできます。着信データトラフィックの場合、セレクタとしてSPIとともにアドレスを使用することを選択できます。アウトバウンドデータトラフィックの場合は、各アドレスのアドレス検証の状態[RFC8046]を考慮し、アドレスが動作状態かどうかに関する利用可能な情報も考慮して、マルチホームホストの使用可能なアドレスから選択する必要があります。
A multihomed host may decide to set up new SA pairs corresponding to new addresses, for the purpose of load balancing. The decision to load balance and the mechanism for splitting load across multiple SAs is out of scope of this document. The scenario can be supported by sending the LOCATOR_SET parameter with one or more ESP_INFO parameters to initiate new ESP SAs. To do this, the multihomed host sends a LOCATOR_SET with an ESP_INFO, indicating the request for a new SA by setting the OLD SPI value to zero and the NEW SPI value to the newly created incoming SPI. A Locator Type of "1" is used to associate the new address with the new SPI. The LOCATOR_SET parameter also contains a second Type "1" Locator, that of the original address and SPI. To simplify parameter processing and avoid explicit protocol extensions to remove locators, each LOCATOR_SET parameter MUST list all locators in use on a connection (a complete listing of inbound locators and SPIs for the host). The multihomed host waits for a corresponding ESP_INFO (new outbound SA) from the peer and an ACK of its own UPDATE. As in the mobility case, the peer host must perform an address verification before actively using the new address.
マルチホームホストは、ロードバランシングの目的で、新しいアドレスに対応する新しいSAペアをセットアップすることを決定できます。負荷分散の決定と、複数のSA間で負荷を分割するメカニズムは、このドキュメントの範囲外です。このシナリオは、LOCATOR_SETパラメーターを1つ以上のESP_INFOパラメーターと共に送信して、新しいESP SAを開始することでサポートできます。これを行うには、マルチホームホストがESP_INFOを含むLOCATOR_SETを送信します。これは、OLD SPI値をゼロに設定し、NEW SPI値を新しく作成された着信SPIに設定することで、新しいSAの要求を示します。ロケータータイプ "1"は、新しいアドレスを新しいSPIに関連付けるために使用されます。 LOCATOR_SETパラメーターには、元のアドレスとSPIの2番目のタイプ「1」ロケーターも含まれます。パラメーターの処理を簡略化し、ロケーターを削除するための明示的なプロトコル拡張を回避するために、各LOCATOR_SETパラメーターは、接続で使用中のすべてのロケーターをリストしなければなりません（ホストのインバウンドロケーターとSPIの完全なリスト）。マルチホームホストは、ピアからの対応するESP_INFO（新しい送信SA）と、自身のUPDATEのACKを待ちます。モビリティの場合と同様に、ピアホストは新しいアドレスをアクティブに使用する前にアドレス検証を実行する必要があります。
Figure 2 illustrates this scenario.
図2は、このシナリオを示しています。
Multihomed Host Peer Host
マルチホームホストピアホスト
UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 2: Host Multihoming for Load Balancing
図2：負荷分散のためのホストマルチホーミング
In multihoming scenarios, it is important that hosts receiving UPDATEs associate them correctly with the destination address used in the packet carrying the UPDATE. When processing inbound LOCATOR_SETs that establish new security associations on an interface with multiple addresses, a host uses the destination address of the UPDATE containing the LOCATOR_SET as the local address to which the LOCATOR_SET plus ESP_INFO is targeted. This is because hosts may send UPDATEs with the same (locator) IP address to different peer addresses -- this has the effect of creating multiple inbound SAs implicitly affiliated with different peer source addresses.
マルチホーミングのシナリオでは、UPDATEを受信するホストが、UPDATEを伝送するパケットで使用される宛先アドレスにそれらを正しく関連付けることが重要です。複数のアドレスを持つインターフェイスで新しいセキュリティアソシエーションを確立するインバウンドLOCATOR_SETを処理するとき、ホストは、LOCATOR_SETとESP_INFOのターゲットとなるローカルアドレスとして、LOCATOR_SETを含むUPDATEの宛先アドレスを使用します。これは、ホストが同じ（ロケーター）IPアドレスを持つUPDATEを異なるピアアドレスに送信する可能性があるためです。これは、異なるピアソースアドレスに暗黙的に関連付けられた複数のインバウンドSAを作成する効果があります。
A host may have an interface that has multiple globally routable IP addresses. Such a situation may be a result of the site having multiple upper Internet Service Providers, or just because the site provides all hosts with both IPv4 and IPv6 addresses. The host should stay reachable at all or any subset of the currently available global routable addresses, independent of how they are provided.
ホストには、グローバルにルーティング可能な複数のIPアドレスを持つインターフェースがある場合があります。このような状況は、サイトに複数の上位インターネットサービスプロバイダーが存在するか、サイトがすべてのホストにIPv4とIPv6の両方のアドレスを提供していることが原因である可能性があります。ホストは、それらがどのように提供されているかに関係なく、現在利用可能なグローバルルーティング可能なアドレスのすべてまたはサブセットに到達可能である必要があります。
This case is handled the same as if there were different IP addresses, described above in Sections 4.2.3 and 4.2.4. Note that a single interface may have addresses corresponding to site multihoming while the host itself may also have multiple network interfaces.
このケースは、上記のセクション4.2.3および4.2.4で説明したように、異なるIPアドレスが存在する場合と同じように処理されます。ホスト自体も複数のネットワークインターフェースを備えている場合がある一方で、単一のインターフェースがサイトマルチホーミングに対応するアドレスを備えている場合があることに注意してください。
Note that a host may be multihomed and mobile simultaneously, and that a multihomed host may want to protect the location of some of its interfaces while revealing the real IP address of some others.
ホストがマルチホームとモバイルの両方である場合や、マルチホームホストが一部のインターフェイスの場所を保護し、他の一部の実際のIPアドレスを明らかにしたい場合があることに注意してください。
This document does not present additional site multihoming extensions to HIP; such extensions are for further study.
このドキュメントでは、HIPに対する追加のサイトマルチホーミング拡張については説明しません。このような拡張機能は、今後の検討課題です。
Consider the case in which both hosts are multihomed and would like to notify the peer of an additional address after the base exchange completes. It may be the case that both hosts choose to simply announce the second address in a LOCATOR_SET parameter using an UPDATE message exchange. It may also be the case that one or both hosts decide to ask for new SA pairs to be created using the newly announced address. In the case that both hosts request this, the result will be a full mesh of SAs as depicted in Figure 3. In such a scenario, consider that host1, which used address addr1a in the base exchange to set up SPI1a and SPI2a, wants to add address addr1b. It would send an UPDATE with LOCATOR_SET (containing the address addr1b) to host2, using destination address addr2a, and a new ESP_INFO, and a new set of SPIs would be added between hosts 1 and 2 (call them SPI1b and SPI2b; not shown in the figure). Next, consider host2 deciding to add addr2b to the relationship. Host2 must select one of host1's addresses towards which to initiate an UPDATE. It may choose to initiate an UPDATE to addr1a, addr1b, or both. If it chooses to send to both, then a full mesh (four SA pairs) of SAs would exist between the two hosts. This is the most general case; the protocol is flexible enough to accommodate this choice.
両方のホストがマルチホームであり、ベース交換の完了後に追加のアドレスをピアに通知する場合を考えます。両方のホストが、UPDATEメッセージ交換を使用して、LOCATOR_SETパラメータで2番目のアドレスを単に通知することを選択する場合があります。また、一方または両方のホストが、新しくアナウンスされたアドレスを使用して新しいSAペアを作成するよう要求することを決定する場合もあります。両方のホストがこれを要求した場合、結果は図3に示すようにSAのフルメッシュになります。そのようなシナリオでは、ベース交換でアドレスaddr1aを使用してSPI1aとSPI2aをセットアップしたhost1が、アドレスaddr1bを追加します。宛先アドレスaddr2aと新しいESP_INFOを使用して、LOCATOR_SET（アドレスaddr1bを含む）を含むUPDATEをhost2に送信し、ホスト1と2の間に新しいSPIセットを追加します（SPI1bとSPI2bと呼びます。図）。次に、host2がaddr2bを関係に追加することを決定することを検討してください。 Host2は、UPDATEを開始するhost1のアドレスの1つを選択する必要があります。 addr1a、addr1b、またはその両方に対してUPDATEを開始することを選択できます。両方に送信することを選択した場合、2つのホスト間にSAのフルメッシュ（4つのSAペア）が存在します。これは最も一般的なケースです。プロトコルは、この選択に対応するのに十分な柔軟性があります。
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
addr1b <---> addr2a (second SA pair)
addr1a <---> addr2b (third SA pair)
addr1b <---> addr2b (fourth SA pair)
Figure 3: Dual-Multihoming Case in which Each Host Uses LOCATOR_SET to Add a Second Address
図3：各ホストがLOCATOR_SETを使用して2番目のアドレスを追加するデュアルマルチホーミングのケース
Mobile hosts may be simultaneously mobile and multihomed, i.e., have multiple mobile interfaces. Furthermore, if the interfaces use different access technologies, it is fairly likely that one of the interfaces may appear stable (retain its current IP address) while some others may experience mobility (undergo IP address change).
モバイルホストは、モバイルとマルチホームの両方である場合があります。つまり、複数のモバイルインターフェイスを備えています。さらに、インターフェイスが異なるアクセステクノロジーを使用している場合、一部のインターフェイスでモビリティが発生する（IPアドレスの変更が行われる）一方で、インターフェイスの1つが安定しているように見える可能性があります（現在のIPアドレスを保持）。
The use of LOCATOR_SET plus ESP_INFO should be flexible enough to handle most such scenarios, although more complicated scenarios have not been studied so far.
より複雑なシナリオはこれまで研究されていませんが、LOCATOR_SETとESP_INFOの使用は、ほとんどのそのようなシナリオを処理するのに十分な柔軟性を持つ必要があります。
A Responder host MAY include a LOCATOR_SET parameter in the R1 packet that it sends to the Initiator. This parameter MUST be protected by the R1 signature. If the R1 packet contains LOCATOR_SET parameters with a new preferred locator, the Initiator SHOULD directly set the new preferred locator to status ACTIVE without performing address verification first, and it MUST send the I2 packet to the new preferred locator. The I1 destination address and the new preferred locator may be identical. All new non-preferred locators must still undergo address verification once the base exchange completes. It is also possible for the host to send the LOCATOR_SET without any preferred bits set, in which case the exchange will continue as normal and the newly learned addresses will be in an UNVERIFIED state at the initiator.
レスポンダホストは、イニシエータに送信するR1パケットにLOCATOR_SETパラメータを含めることができます。このパラメータは、R1シグネチャで保護する必要があります。 R1パケットに新しい優先ロケーターを含むLOCATOR_SETパラメーターが含まれている場合、イニシエーターは最初にアドレス検証を実行せずに新しい優先ロケーターをステータスACTIVEに直接設定する必要があり（SHOULD）、I2パケットを新しい優先ロケーターに送信する必要があります。 I1宛先アドレスと新しい優先ロケーターは同一である場合があります。すべての新しい非優先ロケーターは、ベース交換が完了した後もアドレス検証を受ける必要があります。ホストが優先ビットを設定せずにLOCATOR_SETを送信することも可能です。この場合、交換は通常どおり続行され、新しく学習されたアドレスはイニシエーターでUNVERIFIED状態になります。
Initiator Responder
イニシエーターレスポンダー
R1 with LOCATOR_SET
<-----------------------------------
record additional addresses
change Responder address
I2 sent to newly indicated preferred address
----------------------------------->
(process normally)
R2
<-----------------------------------
(process normally, later verification of non-preferred locators)
Figure 4: LOCATOR_SET Inclusion in R1
図4：R1に含まれるLOCATOR_SET
An Initiator MAY include one or more LOCATOR_SET parameters in the I2 packet, independent of whether or not there was a LOCATOR_SET parameter in the R1. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR_SET parameters, the Responder MUST still send the R2 packet to the source address of the I2. The new preferred locator, if set, SHOULD be identical to the I2 source address. If the I2 packet contains LOCATOR_SET parameters, all new locators must undergo address verification as usual, and the ESP traffic that subsequently follows should use the preferred locator.
イニシエーターは、R1にLOCATOR_SETパラメーターがあったかどうかに関係なく、I2パケットに1つ以上のLOCATOR_SETパラメーターを含めることができます（MAY）。これらのパラメータは、I2シグネチャで保護する必要があります。 I2パケットにLOCATOR_SETパラメータが含まれている場合でも、レスポンダはR2パケットをI2の送信元アドレスに送信する必要があります。新しい優先ロケータは、設定されている場合、I2送信元アドレスと同一である必要があります（SHOULD）。 I2パケットにLOCATOR_SETパラメーターが含まれている場合、すべての新しいロケーターは通常どおりアドレス検証を受ける必要があり、その後に続くESPトラフィックは優先ロケーターを使用する必要があります。
Initiator Responder
イニシエーターレスポンダー
I2 with LOCATOR_SET
----------------------------------->
(process normally)
record additional addresses
R2 sent to source address of I2
<-----------------------------------
(process normally)
Figure 5: LOCATOR_SET Inclusion in I2
図5：I2に含まれるLOCATOR_SET
The I1 and I2 may be arriving from different source addresses if the LOCATOR_SET parameter is present in R1. In this case, implementations simultaneously using multiple pre-created R1s, indexed by Initiator IP addresses, may inadvertently fail the puzzle solution of I2 packets due to a perceived puzzle mismatch. See, for instance, the example in Appendix A of [RFC7401]. As a solution, the Responder's puzzle indexing mechanism must be flexible enough to accommodate the situation when R1 includes a LOCATOR_SET parameter.
LOCATOR_SETパラメータがR1に存在する場合、I1とI2は異なるソースアドレスから到着する可能性があります。この場合、イニシエーターIPアドレスによってインデックスが作成された複数の事前に作成されたR1を同時に使用する実装では、知覚されたパズルの不一致により、I2パケットのパズルソリューションが不注意に失敗する可能性があります。たとえば、[RFC7401]の付録Aの例をご覧ください。解決策として、R1にLOCATOR_SETパラメーターが含まれている状況に対応できるように、レスポンダーのパズルインデックスメカニズムは十分に柔軟でなければなりません。
Finally, the R2 may be used to carry the LOCATOR_SET parameter. In this case, the LOCATOR_SET is covered by the HIP_MAC_2 and HIP_SIGNATURE. Including LOCATOR_SET in R2 as opposed to R1 may have some advantages when a host prefers not to divulge additional locators until after the I2 is successfully processed.
最後に、R2を使用してLOCATOR_SETパラメータを伝達できます。この場合、LOCATOR_SETはHIP_MAC_2およびHIP_SIGNATUREでカバーされます。ホストがI2が正常に処理されるまで追加のロケーターを漏らしたくない場合、R1ではなくR2にLOCATOR_SETを含めると、いくつかの利点があります。
When the LOCATOR_SET parameter is sent in an UPDATE packet, the receiver will respond with an UPDATE acknowledgment. When the LOCATOR_SET parameter is sent in an R1, I2, or R2 packet, the base exchange retransmission mechanism will confirm its successful delivery.
LOCATOR_SETパラメータがUPDATEパケットで送信されると、受信者はUPDATE確認応答で応答します。 LOCATOR_SETパラメータがR1、I2、またはR2パケットで送信されると、ベース交換の再送信メカニズムが正常に配信されたことを確認します。
It is possible for HIP associations to use these mechanisms to migrate their HIP associations and security associations from addresses in the IPv4 addressing realm to IPv6, or vice versa. It may be possible for a state to arise in which both hosts are only using locators in different addressing realms, but in such a case, some type of mechanism for interworking between the different realms must be employed; such techniques are outside the scope of the present text.
HIPアソシエーションがこれらのメカニズムを使用して、HIPアソシエーションとセキュリティアソシエーションをIPv4アドレッシングレルムのアドレスからIPv6に、またはその逆に移行することが可能です。両方のホストが異なるアドレッシングレルムのロケーターのみを使用している状態が発生する可能性がありますが、そのような場合、異なるレルム間の相互作用のために何らかのタイプのメカニズムを使用する必要があります。そのような技法は、現在のテキストの範囲外です。
A host may establish any number of security associations (or SPIs) with a peer. The main purpose of having multiple SPIs with a peer is to group the addresses into collections that are likely to experience fate sharing, or to perform load balancing.
ホストは、ピアとのセキュリティアソシエーション（またはSPI）をいくつでも確立できます。ピアで複数のSPIを使用する主な目的は、運命の共有を経験する可能性が高いコレクションにアドレスをグループ化するか、負荷分散を実行することです。
A basic property of HIP SAs is that the inbound IP address is not used to look up the incoming SA. However, the use of different source and destination addresses typically leads to different paths, with different latencies in the network, and if packets were to arrive via an arbitrary destination IP address (or path) for a given SPI, the reordering due to different latencies may cause some packets to fall outside of the ESP anti-replay window. For this reason, HIP provides a mechanism to affiliate destination addresses with inbound SPIs, when there is a concern that anti-replay windows might be violated. In this sense, we can say that a given inbound SPI has an "affinity" for certain inbound IP addresses, and this affinity is communicated to the peer host. Each physical interface SHOULD have a separate SA, unless the ESP anti-replay window is extended or disabled.
HIP SAの基本的な特性は、着信IPアドレスが着信SAの検索に使用されないことです。ただし、異なる送信元アドレスと宛先アドレスを使用すると、通常、ネットワーク内の異なるレイテンシで異なるパスが発生し、パケットが特定のSPIの任意の宛先IPアドレス（またはパス）経由で到着した場合、異なるレイテンシによる順序変更一部のパケットがESPのアンチリプレイウィンドウの外に出る可能性があります。このため、HIPは、アンチリプレイウィンドウの違反が懸念される場合に、宛先アドレスをインバウンドSPIに関連付けるメカニズムを提供します。この意味で、特定のインバウンドSPIには特定のインバウンドIPアドレスに対する「アフィニティ」があり、このアフィニティはピアホストに通信されると言えます。 ESPアンチリプレイウィンドウが拡張されているか無効になっている場合を除き、各物理インターフェイスには個別のSAが必要です（SHOULD）。
Moreover, even when the destination addresses used for a particular SPI are held constant, the use of different source interfaces may also cause packets to fall outside of the ESP anti-replay window, since the path traversed is often affected by the source address or interface used. A host has no way to influence the source interface on which a peer sends its packets on a given SPI. A host SHOULD consistently use the same source interface and address when sending to a particular destination IP address and SPI. For this reason, a host may find it useful to change its SPI or at least reset its ESP anti-replay window when the peer host readdresses.
さらに、特定のSPIに使用される宛先アドレスが一定に保たれている場合でも、通過するパスは送信元アドレスまたはインターフェースの影響を受けることが多いため、異なる送信元インターフェースを使用すると、パケットがESPアンチリプレイウィンドウの外に落ちることがあります。中古。ホストは、ピアが特定のSPIでパケットを送信する送信元インターフェイスに影響を与える方法はありません。ホストは、特定の宛先IPアドレスとSPIに送信するときに、常に同じソースインターフェイスとアドレスを使用する必要があります（SHOULD）。このため、ピアホストのアドレスが変更されたときに、ホストでSPIを変更するか、少なくともESPアンチリプレイウィンドウをリセットすると便利な場合があります。
Basic processing rules for the LOCATOR_SET parameter are specified in [RFC8046]. This document focuses on multihoming-specific rules.
LOCATOR_SETパラメータの基本的な処理規則は、[RFC8046]で指定されています。このドキュメントでは、マルチホーミング固有のルールに焦点を当てています。
The decision of when to send a LOCATOR_SET, and which addresses to include, is a local policy issue. [RFC8046] recommends that a host "send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association and [when it] assumes that the change is going to last at least for a few seconds." It is possible to delay the exposure of additional locators to the peer, and to send data from previously unannounced locators, as might arise in certain mobility or multihoming situations.
LOCATOR_SETを送信するタイミングと含めるアドレスの決定は、ローカルポリシーの問題です。 [RFC8046]は、ホストが「アクティブなHIPアソシエーションで使用中のIPアドレスの変更を認識し、その変更が少なくとも数秒間続くと想定する場合は常にLOCATOR_SETを送信する」ことを推奨します。特定のモビリティまたはマルチホーミングの状況で発生する可能性があるように、追加のロケーターのピアへの公開を遅らせ、以前に通知されていないロケーターからデータを送信することができます。
When a host decides to inform its peers about changes in its IP addresses, it has to decide how to group the various addresses with SPIs. If hosts are deployed in an operational environment in which HIP-aware NATs and firewalls (that may perform parameter inspection) exist, and different such devices may exist on different paths, hosts may take that knowledge into consideration about how addresses are grouped, and may send the same LOCATOR_SET in separate UPDATEs on the different paths. However, more detailed guidelines about how to operate in the presence of such HIP-aware NATs and firewalls are a topic for further study. Since each SPI is associated with a different security association, the grouping policy may also be based on ESP anti-replay protection considerations. In the typical case, simply basing the grouping on actual kernel-level physical and logical interfaces may be the best policy. The grouping policy is outside of the scope of this document.
ホストがピアにIPアドレスの変更について通知することを決定した場合、ホストはさまざまなアドレスをSPIでグループ化する方法を決定する必要があります。ホストがHIP対応のNATとファイアウォール（パラメーター検査を実行する可能性がある）が存在する運用環境に展開され、そのような異なるデバイスが異なるパスに存在する可能性がある場合、ホストはアドレスをグループ化する方法についてその知識を考慮し、異なるパスの別々のUPDATEで同じLOCATOR_SETを送信します。ただし、このようなHIP対応のNATおよびファイアウォールが存在する場合の運用方法に関するより詳細なガイドラインは、今後の検討課題です。各SPIは異なるセキュリティアソシエーションに関連付けられているため、グループ化ポリシーはESPアンチリプレイ保護の考慮事項に基づいている場合もあります。典型的なケースでは、実際のカーネルレベルの物理および論理インターフェイスに基づいてグループ化するだけが最良のポリシーになる場合があります。グループ化ポリシーは、このドキュメントの範囲外です。
Locators corresponding to tunnel interfaces (e.g., IPsec tunnel interfaces or Mobile IP home addresses) or other virtual interfaces MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid announcing such locators as preferred locators if more direct paths may be obtained by instead preferring locators from non-tunneling interfaces if such locators provide a more direct path to the HIP peer.
トンネルインターフェース（IPsecトンネルインターフェースやモバイルIPホームアドレスなど）またはその他の仮想インターフェースに対応するロケーターはLOCATOR_SETでアナウンスされる場合がありますが、実装では、ロケーターを優先してより直接的なパスを取得できる場合は、そのようなロケーターを優先ロケーターとしてアナウンスしないでください。そのようなロケーターがHIPピアへのより直接的なパスを提供する場合、非トンネリングインターフェイス。
[RFC8046] specifies that hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. Link-local addresses MAY be announced to peers that are known to be neighbors on the same link, such as when the IP destination address of a peer is also link local. The announcement of link-local addresses in this case is a policy decision; link-local addresses used as preferred locators will create reachability problems when the host moves to another link. In any case, link-local addresses MUST NOT be announced to a peer unless that peer is known to be on the same link.
[RFC8046]は、ホストがLOCATOR_SETでブロードキャストまたはマルチキャストアドレスを通知してはならないことを指定します。リンクローカルアドレスは、ピアのIP宛先アドレスもリンクローカルである場合など、同じリンク上のネイバーであることがわかっているピアに通知される場合があります。この場合のリンクローカルアドレスのアナウンスはポリシー決定です。優先ロケーターとして使用されるリンクローカルアドレスは、ホストが別のリンクに移動するときに到達可能性の問題を引き起こします。いずれの場合も、ピアが同じリンク上にあることがわかっている場合を除き、リンクローカルアドレスをピアに通知しないでください。
Once the host has decided on the groups and assignment of addresses to the SPIs, it creates a LOCATOR_SET parameter that serves as a complete representation of the addresses and associated SPIs intended for active use. We now describe a few cases introduced in Section 4. We assume that the Traffic Type for each locator is set to "0" (other values for Traffic Type may be specified in documents that separate the HIP control plane from data-plane traffic). Other mobility and multihoming cases are possible but are left for further experimentation.
ホストがグループとSPIへのアドレスの割り当てを決定すると、ホストは、LOCATOR_SETパラメーターを作成します。このパラメーターは、アクティブな使用を目的としたアドレスと関連するSPIの完全な表現として機能します。次に、セクション4で紹介したいくつかのケースについて説明します。各ロケーターのトラフィックタイプが「0」に設定されていると仮定します（トラフィックタイプの他の値は、HIPコントロールプレーンをデータプレーントラフィックから分離するドキュメントで指定できます）。他のモビリティおよびマルチホーミングのケースも可能ですが、さらなる実験のために残されています。
1. Host multihoming (addition of an address). We only describe the simple case of adding an additional address to a (previously) single-homed, non-mobile host. The host MAY choose to simply announce this address to the peer, for fault tolerance. To do this, the multihomed host creates a LOCATOR_SET parameter including the existing address and SPI as a Type "1" Locator, and the new address as a Type "0" Locator. The host sends this in an UPDATE message with the SEQ parameter, which is acknowledged by the peer.
1. ホストマルチホーミング（アドレスの追加）。 （以前は）シングルホームの非モバイルホストにアドレスを追加する単純なケースについてのみ説明します。ホストは、フォールトトレランスのために、このアドレスをピアに単に通知することを選択できます。これを行うために、マルチホームホストは、既存のアドレスとSPIをタイプ「1」ロケーターとして、新しいアドレスをタイプ「0」ロケーターとして含むLOCATOR_SETパラメーターを作成します。ホストはこれを、ピアが確認応答するSEQパラメータを含むUPDATEメッセージで送信します。
2. The host MAY set up a new SA pair between this new address and an address of the peer host. To do this, the multihomed host creates a new inbound SA and creates a new SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter with an OLD SPI field of "0", a NEW SPI field corresponding to the new SPI, and a KEYMAT Index as selected by local policy. The host adds to the UPDATE message a LOCATOR_SET with two Type "1" Locators: the original address and SPI active on the association, and the new address and new SPI being added (with the SPI matching the NEW SPI contained in the ESP_INFO). The preferred bit SHOULD be set depending on the policy to tell the peer host which of the two locators is preferred. The UPDATE also contains a SEQ parameter and optionally a DIFFIE_HELLMAN parameter and follows rekeying procedures with respect to this new address. The UPDATE message SHOULD be sent to the peer's preferred address with a source address corresponding to the new locator.
2. ホストは、この新しいアドレスとピアホストのアドレスの間に新しいSAペアを設定する場合があります。これを行うには、マルチホームホストが新しい受信SAを作成し、新しいSPIを作成します。発信UPDATEメッセージの場合、OLD SPIフィールドが「0」のESP_INFOパラメータ、新しいSPIに対応するNEW SPIフィールド、およびローカルポリシーで選択されたKEYMATインデックスが挿入されます。ホストは、UPDATEメッセージに2つのタイプ "1"ロケーターを持つLOCATOR_SETを追加します。関連付けで元のアドレスとSPIがアクティブになり、新しいアドレスと新しいSPIが追加されます（SPIはESP_INFOに含まれるNEW SPIと一致します）。 2つのロケーターのどちらを優先するかをピアホストに伝えるポリシーに応じて、優先ビットを設定する必要があります（SHOULD）。 UPDATEには、SEQパラメータと、オプションでDIFFIE_HELLMANパラメータも含まれており、この新しいアドレスに関して鍵の更新手順に従います。 UPDATEメッセージは、新しいロケーターに対応する送信元アドレスとともにピアの優先アドレスに送信する必要があります（SHOULD）。
The sending of multiple LOCATOR_SETs is unsupported. Note that the inclusion of LOCATOR_SET in an R1 packet requires the use of Type "0" Locators since no SAs are set up at that point.
複数のLOCATOR_SETの送信はサポートされていません。 LOCATOR_SETをR1パケットに含めるには、SAがセットアップされていないため、タイプ "0"のロケーターを使用する必要があることに注意してください。
A host SHOULD be prepared to receive a LOCATOR_SET parameter in the following HIP packets: R1, I2, R2, and UPDATE.
ホストは、HIPパケットR1、I2、R2、およびUPDATEでLOCATOR_SETパラメータを受信できるように準備する必要があります。
This document describes sending both ESP_INFO and LOCATOR_SET parameters in an UPDATE. The ESP_INFO parameter is included when there is a need to rekey or key a new SPI and can otherwise be included for the possible benefit of HIP-aware middleboxes. The LOCATOR_SET parameter contains a complete map of the locators that the host wishes to make or keep active for the HIP association.
このドキュメントでは、UPDATEでESP_INFOパラメータとLOCATOR_SETパラメータの両方を送信する方法について説明します。 ESP_INFOパラメータは、新しいSPIのキーを再生成またはキー入力する必要がある場合に含まれます。それ以外の場合は、HIP対応ミドルボックスの利点のために含めることができます。 LOCATOR_SETパラメータには、ホストがHIPアソシエーションのためにアクティブにするか維持したいロケータの完全なマップが含まれています。
In general, the processing of a LOCATOR_SET depends upon the packet type in which it is included. Here, we describe only the case in which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are sent in an UPDATE message; other cases are for further study. The steps below cover each of the cases described in Section 5.1.
一般に、LOCATOR_SETの処理は、LOCATOR_SETが含まれるパケットタイプによって異なります。ここでは、ESP_INFOが存在し、単一のLOCATOR_SETおよびESP_INFOがUPDATEメッセージで送信される場合についてのみ説明します。他のケースはさらなる研究のためです。以下のステップは、セクション5.1で説明されている各ケースをカバーしています。
The processing of ESP_INFO and LOCATOR_SET parameters is intended to be modular and support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR_SET parameters. A host SHOULD first process the ESP_INFO before the LOCATOR_SET, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Type "1" Locator will only contain a reference to the new SPI.
ESP_INFOおよびLOCATOR_SETパラメータの処理はモジュール化され、複数のESP_INFOおよび/または複数のLOCATOR_SETパラメータを含めるための将来の一般化をサポートすることを目的としています。 ESH_INFOには既存のSPIにマップされた新しいSPI値が含まれる場合があるため、ホストは最初にESP_INFOをLOCATOR_SETの前に処理する必要があります。一方、タイプ "1"ロケーターには新しいSPIへの参照のみが含まれます。
When a host receives a validated HIP UPDATE with a LOCATOR_SET and ESP_INFO parameter, it processes the ESP_INFO as follows. The ESP_INFO parameter indicates whether an SA is being rekeyed, created, deprecated, or just identified for the benefit of middleboxes. The host examines the OLD SPI and NEW SPI values in the ESP_INFO parameter:
ホストは、LOCATOR_SETおよびESP_INFOパラメーターを使用して検証済みのHIP UPDATEを受信すると、ESP_INFOを次のように処理します。 ESP_INFOパラメーターは、ミドルボックスのメリットのために、SAのキーの再生成、作成、非推奨、または識別のみを行うかどうかを示します。ホストは、ESP_INFOパラメータのOLD SPIおよびNEW SPI値を調べます。
1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both correspond to an existing SPI, the ESP_INFO is gratuitous (provided for middleboxes), and no rekeying is necessary.
1. （キーの再生成なし）OLD SPIがNEW SPIと等しく、両方が既存のSPIに対応している場合、ESP_INFOは無償（ミドルボックスに提供）であり、キー再生成の必要はありません。
2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW SPI is a different non-zero value, the existing SA is being rekeyed and the host follows HIP ESP rekeying procedures by creating a new outbound SA with an SPI corresponding to the NEW SPI, with no addresses bound to this SPI. Note that locators in the LOCATOR_SET parameter will reference this new SPI instead of the old SPI.
2. （キーの再生成）OLD SPIが既存のSPIを示しており、NEW SPIがゼロ以外の異なる値である場合、既存のSAはキーが再生成され、ホストはNEWに対応するSPIで新しいアウトバウンドSAを作成することにより、HIP ESPキー再生成手順に従いますSPI。このSPIにバインドされたアドレスはありません。 LOCATOR_SETパラメータのロケータは、古いSPIではなく、この新しいSPIを参照することに注意してください。
3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new non-zero value, then a new SA is being requested by the peer. This case is also treated like a rekeying event; the receiving host must create a new SA and respond with an UPDATE ACK.
3. （新しいSA）OLD SPI値がゼロであり、NEW SPIがゼロ以外の新しい値である場合、ピアによって新しいSAが要求されています。この場合も、キー再生成イベントのように扱われます。受信ホストは新しいSAを作成し、UPDATE ACKで応答する必要があります。
4. (deprecating the SA) If the OLD SPI indicates an existing SPI and the NEW SPI is zero, the SA is being deprecated and all locators uniquely bound to the SPI are put into the DEPRECATED state.
4. （SAの非推奨）OLD SPIが既存のSPIを示し、NEW SPIがゼロの場合、SAは非推奨になり、SPIに一意にバインドされたすべてのロケーターはDEPRECATED状態になります。
If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped.
上記のいずれにも当てはまらない場合は、プロトコルエラーが発生しているため、UPDATEの処理は停止しています。
Next, the locators in the LOCATOR_SET parameter are processed. For each locator listed in the LOCATOR_SET parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address. Note that some implementations MAY accept addresses that indicate the local host, since it may be allowed that the host runs HIP with itself.
次に、LOCATOR_SETパラメーターのロケーターが処理されます。 LOCATOR_SETパラメーターにリストされているロケーターごとに、そのアドレスが有効なユニキャストまたはエニーキャストアドレスであることを確認します。つまり、アドレスはブロードキャストまたはマルチキャストアドレスであってはなりません。ホスト自体がHIPを実行することが許可される場合があるため、一部の実装はローカルホストを示すアドレスを受け入れる場合があります。
For each Type "1" address listed in the LOCATOR_SET parameter, the host checks whether the address is already bound to the SPI indicated. If the address is already bound, its lifetime is updated. If the status of the address is DEPRECATED, the status is changed to UNVERIFIED. If the address is not already bound, the address is added, and its status is set to UNVERIFIED. If there exist remaining addresses corresponding to the SPI that were NOT listed in the LOCATOR_SET parameter, the host sets the status of such addresses to DEPRECATED.
LOCATOR_SETパラメータにリストされている各タイプ「1」アドレスについて、ホストは、アドレスが指定されたSPIにすでにバインドされているかどうかを確認します。アドレスが既にバインドされている場合、その存続期間は更新されます。アドレスのステータスがDEPRECATEDの場合、ステータスはUNVERIFIEDに変更されます。アドレスがまだバインドされていない場合、アドレスが追加され、そのステータスはUNVERIFIEDに設定されます。 LOCATOR_SETパラメーターにリストされていないSPIに対応する残りのアドレスが存在する場合、ホストはそのようなアドレスのステータスをDEPRECATEDに設定します。
For each Type "0" address listed in the LOCATOR_SET parameter, if the status of the address is DEPRECATED, or the address was not previously known, the status is changed to UNVERIFIED. The host MAY choose to associate this address with one or more SAs. The association with different SAs is a local policy decision, unless the peer has indicated that the address is preferred, in which case the address should be put into use on an SA that is prioritized in the security policy database.
LOCATOR_SETパラメーターにリストされている各タイプ「0」アドレスについて、アドレスの状況が非推奨であるか、アドレスが以前に知られていない場合、状況はUNVERIFIEDに変更されます。ホストは、このアドレスを1つ以上のSAに関連付けることを選択できます（MAY）。ピアがアドレスを優先することを示していない限り、異なるSAとの関連付けはローカルポリシーの決定です。その場合、アドレスはセキュリティポリシーデータベースで優先されるSAで使用する必要があります。
As a result, at the end of processing, the addresses listed in the LOCATOR_SET parameter have a state of either UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR_SET parameter have a state of DEPRECATED.
その結果、処理の終わりに、LOCATOR_SETパラメーターにリストされているアドレスの状態はUNVERIFIEDまたはACTIVEになり、LOCATOR_SETパラメーターにリストされていない古いSAの古いアドレスの状態はDEPRECATEDになります。
Once the host has processed the locators, if the LOCATOR_SET parameter contains a new preferred locator, the host SHOULD initiate a change of the preferred locator. This requires that the host first verifies reachability of the associated address and only then changes the preferred locator; see Section 5.4.
ホストがロケーターを処理した後、LOCATOR_SETパラメーターに新しい優先ロケーターが含まれている場合、ホストは優先ロケーターの変更を開始する必要があります（SHOULD）。これには、ホストが関連付けられたアドレスの到達可能性を最初に確認してから、優先ロケーターを変更する必要があります。セクション5.4を参照してください。
If a host receives a locator with an unsupported Locator Type, and when such a locator is also declared to be the preferred locator for the peer, the host SHOULD send a NOTIFY error with a Notify Message Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field containing the locator(s) that the receiver failed to process. Otherwise, a host MAY send a NOTIFY error if a (non-preferred) locator with an unsupported Locator Type is received in a LOCATOR_SET parameter.
ホストがサポートされていないロケータータイプのロケーターを受信し、そのようなロケーターがピアの優先ロケーターであると宣言されている場合、ホストは、通知メッセージタイプがLOCATOR_TYPE_UNSUPPORTEDのNOTIFYエラーを送信し、通知データフィールドにレシーバーが処理に失敗したロケーター。それ以外の場合、サポートされていないロケータータイプの（推奨されない）ロケーターがLOCATOR_SETパラメーターで受信された場合、ホストはNOTIFYエラーを送信できます（MAY）。
Address verification is defined in [RFC8046].
アドレス検証は[RFC8046]で定義されています。
When address verification is in progress for a new preferred locator, the host SHOULD select a different locator listed as ACTIVE, if one such locator is available, to continue communications until address verification completes. Alternatively, the host MAY use the new preferred locator while in UNVERIFIED status to the extent Credit-Based Authorization permits. Credit-Based Authorization is explained in [RFC8046]. Once address verification succeeds, the status of the new preferred locator changes to ACTIVE.
新しい優先ロケーターのアドレス検証が進行中の場合、ホストは、そのロケーターが使用可能な場合、ACTIVEとしてリストされている別のロケーターを選択して、アドレス検証が完了するまで通信を継続する必要があります（SHOULD）。あるいは、ホストは、信用ベースの許可が許可する範囲でUNVERIFIEDステータスにある間、新しい優先ロケーターを使用してもよい（MAY）。クレジットベースの承認は[RFC8046]で説明されています。住所の検証が成功すると、新しい優先ロケーターのステータスがACTIVEに変わります。
A host MAY want to change the preferred outgoing locator for different reasons, e.g., because traffic information or ICMP error messages indicate that the currently used preferred address may have become unreachable. Another reason may be due to receiving a LOCATOR_SET parameter that has the preferred bit set.
ホストは、たとえば現在使用されている優先アドレスが到達不能になった可能性があることをトラフィック情報またはICMPエラーメッセージが示すためなど、さまざまな理由で優先送信ロケーターを変更する必要があります。別の理由としては、優先ビットが設定されているLOCATOR_SETパラメータを受け取ったことが考えられます。
To change the preferred locator, the host initiates the following procedure:
優先ロケーターを変更するには、ホストは次の手順を開始します。
1. If the new preferred locator has ACTIVE status, the preferred locator is changed and the procedure succeeds.
1. 新しい優先ロケーターのステータスがACTIVEの場合、優先ロケーターが変更され、手順は成功します。
2. If the new preferred locator has UNVERIFIED status, the host starts to verify its reachability. The host SHOULD use a different locator listed as ACTIVE until address verification completes if one such locator is available. Alternatively, the host MAY use the new preferred locator, even though in UNVERIFIED status, to the extent Credit-Based Authorization permits. Once address verification succeeds, the status of the new preferred locator changes to ACTIVE, and its use is no longer governed by Credit-Based Authorization.
2. 新しい優先ロケーターのステータスがUNVERIFIEDの場合、ホストは到達可能性の検証を開始します。ホストは、そのようなロケーターが1つでも利用できる場合にアドレス検証が完了するまで、ACTIVEとしてリストされている別のロケーターを使用する必要があります（SHOULD）。あるいは、ホストは、信用ベースの許可が許可する範囲内で、未確認ステータスであっても、新しい優先ロケーターを使用してもよい（MAY）。住所の検証が成功すると、新しい優先ロケーターのステータスがACTIVEに変わり、その使用はクレジットベースの承認によって管理されなくなります。
3. If the peer host has not indicated a preference for any address, then the host picks one of the peer's ACTIVE addresses randomly or according to policy. This case may arise if, for example, ICMP error messages that deprecate the preferred locator arrive, but the peer has not yet indicated a new preferred locator.
3. ピアホストがどのアドレスにも優先順位を指定していない場合、ホストはピアのアクティブアドレスの1つをランダムに、またはポリシーに従って選択します。このケースは、たとえば、優先ロケーターを廃止するICMPエラーメッセージが到着したが、ピアがまだ新しい優先ロケーターを示していない場合に発生する可能性があります。
4. If the new preferred locator has DEPRECATED status and there is at least one non-deprecated address, the host selects one of the non-deprecated addresses as a new preferred locator and continues. If the selected address is UNVERIFIED, the address verification procedure described above will apply.
4. 新しい優先ロケーターのステータスが非推奨で、非推奨のアドレスが少なくとも1つある場合、ホストは非推奨アドレスの1つを新しい優先ロケーターとして選択して続行します。選択した住所が未確認の場合は、上記の住所確認手順が適用されます。
This document extends the scope of host mobility solutions defined in [RFC8046] to also include host multihoming, and as a result, many of the same security considerations for mobility also pertain to multihoming. In particular, [RFC8046] describes how HIP host mobility is resistant to different types of impersonation attacks and denial-of-service (DoS) attacks.
このドキュメントは、[RFC8046]で定義されているホストモビリティソリューションの範囲を拡張して、ホストのマルチホーミングも含めるようにします。その結果、モビリティに関する同じセキュリティの考慮事項の多くがマルチホーミングにも関係します。特に、[RFC8046]は、HIPホストモビリティがさまざまなタイプのなりすまし攻撃およびサービス拒否（DoS）攻撃に対してどのように耐性があるかを説明しています。
The security considerations for this document are similar to those of [RFC8046] because the strong authentication capabilities for mobility also carry over to end-host multihoming. [RFC4218] provides a threat analysis for IPv6 multihoming, and the remainder of this section first describes how HIP host multihoming addresses those previously described threats, and then it discusses some additional security considerations.
このドキュメントのセキュリティに関する考慮事項は、[RFC8046]のセキュリティに関する考慮事項と同様です。モビリティのための強力な認証機能もエンドホストマルチホーミングに引き継がれるためです。 [RFC4218]はIPv6マルチホーミングの脅威分析を提供します。このセクションの残りの部分では、最初にHIPホストマルチホーミングが前述の脅威にどのように対処するかを説明し、次にいくつかの追加のセキュリティ考慮事項について説明します。
The high-level threats discussed in [RFC4218] involve redirection attacks for the purposes of packet recording, data manipulation, and availability. There are a few types of attackers to consider: on-path attackers, off-path attackers, and malicious hosts.
[RFC4218]で説明されている高レベルの脅威には、パケットの記録、データ操作、および可用性を目的としたリダイレクト攻撃が含まれます。考慮すべき攻撃者にはいくつかのタイプがあります：オンパス攻撃者、オフパス攻撃者、および悪意のあるホスト。
[RFC4218] also makes the comment that in identifier/locator split solutions such as HIP, application security mechanisms should be tied to the identifier, not the locator, and attacks on the identifier mechanism and on the mechanism binding locators to the identifier are of concern. This document does not consider the former issue (application-layer security bindings) to be within scope. The latter issue (locator bindings to identifier) is directly addressed by the cryptographic protections of the HIP protocol, in that locators associated to an identifier are listed in HIP packets that are signed using the identifier key.
[RFC4218]はまた、HIPなどの識別子/ロケータ分割ソリューションでは、アプリケーションセキュリティメカニズムをロケータではなく識別子に関連付ける必要があり、識別子メカニズムへの攻撃とロケータを識別子にバインドするメカニズムへの攻撃が懸念される。このドキュメントでは、前の問題（アプリケーション層のセキュリティバインディング）は範囲内であるとは見なされていません。後者の問題（識別子へのロケーターのバインド）は、HIPプロトコルの暗号化保護によって直接対処されます。識別子に関連付けられたロケーターは、識別子キーを使用して署名されたHIPパケットにリストされます。
Section 3.1 of [RFC4218] lists several classes of security configurations in use in the Internet. HIP maps to the fourth (strong identifier) and fifth ("leap-of-faith") categories, the latter being associated with the optional opportunistic mode of HIP operation. The remainder of Section 3 describes existing security problems in the Internet and comments that the goal of a multihoming solution is not to solve them specifically but rather not to make any of them worse. HIP multihoming should not increase the severity of the identified risks. One concern for both HIP mobility and multihoming is the susceptibility of the mechanisms to misuse flooding-based redirections due to a malicious host. The mechanisms described in [RFC8046] for address verification are important in this regard.
[RFC4218]のセクション3.1には、インターネットで使用されているセキュリティ構成のクラスがいくつかリストされています。 HIPは、4番目（強力な識別子）および5番目（「リープオブフェイス」）のカテゴリにマップします。後者は、HIP操作のオプションの便宜的モードに関連付けられています。セクション3の残りの部分では、インターネットの既存のセキュリティ問題について説明し、マルチホーミングソリューションの目標は、それらを具体的に解決することではなく、悪化させることではないとコメントしています。 HIPマルチホーミングは、特定されたリスクの重大度を増加させるべきではありません。 HIPモビリティとマルチホーミングの両方に関する1つの懸念は、悪意のあるホストが原因で、フラッディングベースのリダイレクトを誤用するメカニズムの脆弱性です。 [RFC8046]で説明されているアドレス検証のメカニズムは、この点で重要です。
Regarding the new types of threats introduced by multihoming (Section 4 of [RFC4218]), HIP multihoming should not introduce new concerns. Classic and premeditated redirection are prevented by the strong authentication in HIP messages. Third-party DoS attacks are prevented by the address verification mechanism. Replay attacks can be avoided via use of replay protection in ESP SAs. In addition, accepting packets from unknown locators is protected by either the strong authentication in the HIP control packets or by the ESP-based encryption in use for data packets.
マルチホーミングによってもたらされる新しいタイプの脅威（[RFC4218]のセクション4）に関して、HIPマルチホーミングは新しい懸念をもたらすべきではありません。 HIPメッセージの強力な認証により、クラシックなリダイレクトと計画的なリダイレクトが防止されます。サードパーティのDoS攻撃は、アドレス検証メカニズムによって防止されます。 ESP SAでリプレイ保護を使用することにより、リプレイ攻撃を回避できます。さらに、不明なロケーターからのパケットの受け入れは、HIP制御パケットの強力な認証、またはデータパケットに使用されているESPベースの暗号化によって保護されます。
The HIP mechanisms are designed to limit the ability to introduce DoS on the mechanisms themselves (Section 7 of [RFC4218]). Care is taken in the HIP base exchange to avoid creating state or performing much work before hosts can authenticate one another. A malicious host involved in HIP multihoming with another host might attempt to misuse the mechanisms for multihoming by, for instance, increasing the state required or inducing a resource limitation attack by sending too many candidate locators to the peer host. Therefore, implementations supporting the multihoming extensions should consider avoiding accepting large numbers of peer locators and rate limiting any UPDATE messages being exchanged.
HIPメカニズムは、メカニズム自体にDoSを導入する機能を制限するように設計されています（[RFC4218]のセクション7）。ホストが互いに認証する前に状態を作成したり、多くの作業を実行したりしないように、HIPベース交換では注意が必要です。別のホストとのHIPマルチホーミングに関係する悪意のあるホストは、たとえば、必要な状態を増やしたり、候補ロケーターをピアホストに送信しすぎてリソース制限攻撃を引き起こしたりすることにより、マルチホーミングのメカニズムを誤用しようとする可能性があります。したがって、マルチホーミング拡張をサポートする実装では、多数のピアロケーターの受け入れと、交換されるUPDATEメッセージのレート制限を回避することを検討する必要があります。
The exposure of a host's IP addresses through HIP mobility and multihoming extensions may raise the following privacy concern. The administrator of a host may be trying to hide its location in some context through the use of a VPN or other virtual interfaces. Similar privacy issues also arise in other frameworks such as WebRTC and are not specific to HIP. Implementations SHOULD provide a mechanism to allow the host administrator to block the exposure of selected addresses or address ranges.
HIPモビリティおよびマルチホーミング拡張機能によるホストのIPアドレスの露出は、次のプライバシー問題を引き起こす可能性があります。ホストの管理者は、VPNまたはその他の仮想インターフェイスを使用して、ある状況でその場所を隠そうとしている可能性があります。同様のプライバシー問題は、WebRTCなどの他のフレームワークでも発生し、HIPに固有のものではありません。実装は、ホスト管理者が選択したアドレスまたはアドレス範囲の公開をブロックできるようにするメカニズムを提供する必要があります（SHOULD）。
Finally, some implementations of VPN tunneling have experienced instances of 'leakage' of flows that were intended to have been protected by a security tunnel but are instead sent in the clear, perhaps because some of the addresses used fall outside of the range of addresses configured for the tunnel in the security policy or association database. Implementors are advised to take steps to ensure that the usage of multiple addresses between hosts does not cause accidental leakage of some data session traffic outside of the ESP-protected envelope.
最後に、VPNトンネリングの一部の実装では、セキュリティトンネルで保護することを目的としたフローの「漏洩」のインスタンスが発生しましたが、代わりにクリアテキストで送信されました。セキュリティポリシーまたは関連付けデータベースのトンネル用。実装者は、ホスト間で複数のアドレスを使用しても、ESPで保護されたエンベロープの外にあるデータセッショントラフィックが偶発的に漏洩しないようにするための対策を講じることをお勧めします。
[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>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<http://www.rfc-editor.org/info/rfc6724>。
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <http://www.rfc-editor.org/info/rfc7401>.
[RFC7401] Moskowitz、R。、編、Heer、T.、Jokela、P。、およびT. Henderson、「Host Identity Protocol Version 2（HIPv2）」、RFC 7401、DOI 10.17487 / RFC7401、2015年4月、<http ：//www.rfc-editor.org/info/rfc7401>。
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, <http://www.rfc-editor.org/info/rfc7402>.
[RFC7402] Jokela、P.、Moskowitz、R。、およびJ. Melen、「Using the Encapsulating Security Payload（ESP）Transport Format with the Host Identity Protocol（HIP）」、RFC 7402、DOI 10.17487 / RFC7402、2015年4月、 <http://www.rfc-editor.org/info/rfc7402>。
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, <http://www.rfc-editor.org/info/rfc8046>.
[RFC8046] Henderson、T.、Ed。、Vogt、C。、およびJ. Arkko、「Host Identity Mobility with the Host Identity Protocol」、RFC 8046、DOI 10.17487 / RFC8046、2017年2月、<http：//www.rfc -editor.org/info/rfc8046>。
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, October 2005, <http://www.rfc-editor.org/info/rfc4218>.
[RFC4218] Nordmark、E。およびT. Li、「IPv6マルチホーミングソリューションに関連する脅威」、RFC 4218、DOI 10.17487 / RFC4218、2005年10月、<http://www.rfc-editor.org/info/rfc4218>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.
[RFC5533] Nordmark、E。およびM. Bagnulo、「Shim6：Level 3 Multihoming Shim Protocol for IPv6」、RFC 5533、DOI 10.17487 / RFC5533、2009年6月、<http://www.rfc-editor.org/info/ rfc5533>。
Acknowledgments
謝辞
This document contains content that was originally included in RFC 5206. Pekka Nikander and Jari Arkko originated RFC 5206, and Christian Vogt and Thomas Henderson (editor) later joined as coauthors. Also in RFC 5206, Greg Perkins contributed the initial draft of the security section, and Petri Jokela was a coauthor of the initial individual submission.
このドキュメントには、元々RFC 5206に含まれていた内容が含まれています。PekkaNikanderとJari ArkkoがRFC 5206を作成し、後にChristian VogtとThomas Henderson（編集者）が共同執筆者として参加しました。また、RFC 5206では、Greg Perkinsがセキュリティセクションの最初のドラフトを提供し、Petri Jokelaが最初の個別提出の共著者でした。
The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document. Concepts from a paper on host multihoming across address families, by Samu Varjonen, Miika Komu, and Andrei Gurtov, contributed to this revised specification.
著者は、ドキュメントの多くの改良について、Miika Komu、Mika Kousa、Jeff Ahrenholz、Jan Melenに感謝します。 Samu Varjonen、Miika Komu、Andrei Gurtovによる、アドレスファミリ全体にわたるホストマルチホーミングに関する論文の概念が、この改訂された仕様に貢献しました。
Authors' Addresses
著者のアドレス
Thomas R. Henderson (editor) University of Washington Campus Box 352500 Seattle, WA United States of America
トーマスR.ヘンダーソン（編集者）ワシントン大学キャンパスボックス352500シアトル、ワシントン州アメリカ合衆国
Email: tomhend@u.washington.edu
Christian Vogt Independent 3473 North First Street San Jose, CA 95134 United States of America
クリスチャンフォークト独立3473 North First Street San Jose、CA 95134アメリカ合衆国
Email: mail@christianvogt.net
Jari Arkko Ericsson Jorvas, FIN-02420 Finland
Jari Arkko Ericsson Jorvas、FIN-02420フィンランド
Phone: +358 40 5079256
Email: jari.arkko@piuha.net