Network Working Group P. Nikander
Request for Comments: 5206 Ericsson Research NomadicLab
Category: Experimental T. Henderson, Ed.
The Boeing Company
C. Vogt
J. Arkko
Ericsson Research NomadicLab
April 2008
End-Host Mobility and Multihoming with the Host Identity Protocol
ホストアイデンティティプロトコルとエンドホストモビリティとマルチホーミング
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Abstract
抽象
This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study.
この文書では、ホスト識別プロトコル（HIP）に移動性とマルチホーミング拡張を定義します。具体的には、このドキュメントは、それに到達することができるで代替アドレスに関するピアに通知するHIPホストを可能にするHIPメッセージの一般的な「LOCATOR」パラメータを定義します。ホストが動的にそれがパケットを受信するために使用する一次ロケータを変更するプロセス - この文書はまた、HIPホストのモビリティ手順の要素を定義します。同じLOCATORパラメータは、エンドホストマルチホーミングをサポートするために使用することができますが、詳細な手順は、さらなる研究のために残されています。
Table of Contents
目次
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5
3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8
3.1.3. Multihoming Overview . . . . . . . . . . . . . . . . . 8
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 9
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated
Rekey) . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Host Multihoming . . . . . . . . . . . . . . . . . . . 11
3.2.4. Site Multihoming . . . . . . . . . . . . . . . . . . . 13
3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 14
3.2.6. Combined Mobility and Multihoming . . . . . . . . . . 14
3.2.7. Using LOCATORs across Addressing Realms . . . . . . . 14
3.2.8. Network Renumbering . . . . . . . . . . . . . . . . . 15
3.2.9. Initiating the Protocol in R1 or I2 . . . . . . . . . 15
3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 16
3.3.1. Address Verification . . . . . . . . . . . . . . . . . 16
3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 17
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 18
3.3.4. Interaction with Security Associations . . . . . . . . 18
4. LOCATOR Parameter Format . . . . . . . . . . . . . . . . . . . 21
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 23
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 23
4.3. UPDATE Packet with Included LOCATOR . . . . . . . . . . . 24
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Locator Data Structure and Status . . . . . . . . . . . . 24
5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 25
5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 28
5.4. Verifying Address Reachability . . . . . . . . . . . . . . 30
5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 31
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 32
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 32
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 35
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 36
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 36
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 36
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative references . . . . . . . . . . . . . . . . . . . 38
9.2. Informative references . . . . . . . . . . . . . . . . . . 38
The Host Identity Protocol [RFC4423] (HIP) 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 [RFC5201].
ホスト識別プロトコル[RFC4423]（HIP）は、ホストとして、IPアドレスの代わりに、公開鍵/秘密鍵のペアを使用してインターネットワーキング層（IPv4とIPv6）からのトランスポート層（TCP、UDPなど）を切り離すアーキテクチャをサポートしていますアイデンティティ。ホストはHIP、上層のプロトコル副層を使用する場合（例えば、トランスポート層ソケットとは、カプセル化セキュリティペイロード（ESP）セキュリティアソシエーション（SA））の代わりに、これらのホストアイデンティティの表現に結合され、IPアドレスのみパケット転送のために使用されます。しかし、各ホストは、そのピアが到達可能である時に少なくとも1つのIPアドレスを知っている必要があります。最初は、これらのIPアドレスは、HIPベース交換[RFC5201]の間に使用されるものです。
One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. There are potentially many variations of mobility and multihoming possible. The scope of this document encompasses messaging and elements of procedure for basic network-level mobility and simple multihoming, leaving more complicated scenarios and other variations for further study. More specifically:
そのようなデカップリングの1つの結果は、モビリティとホストマルチホーミング層のネットワークに新しいソリューションが可能であることです。モビリティとマルチホーミング可能性の潜在的に多くのバリエーションがあります。この文書の範囲は、より複雑なシナリオやさらなる研究のための他のバリエーションを残して、メッセージングおよび基本的なネットワークレベルの移動性とシンプルなマルチホーミングのための手順の要素を包含しています。すなわち：
This document defines a generalized LOCATOR parameter for use in HIP messages. The LOCATOR parameter allows a HIP host to notify a peer about alternate addresses at which it is reachable. The LOCATORs may be merely IP addresses, or they may have additional multiplexing and demultiplexing context to aid the packet handling in the lower layers. For instance, an IP address may need to be paired with an ESP Security Parameter Index (SPI) so that packets are sent on the correct SA for a given address.
この文書では、HIPメッセージで使用するための一般LOCATORパラメータを定義します。 LOCATORパラメータは、HIPホストは、それが到達された代替アドレスに関するピアに通知することを可能にします。ロケータは、単にIPアドレスであってもよいし、あるいは、それらは下位層でパケット処理を支援するため、追加の多重化および逆多重化コンテキストを有することができます。例えば、IPアドレスは、パケットが指定されたアドレスの正しいSAに送信されるように、ESPセキュリティパラメータインデックス（SPI）とペアにする必要があるかもしれません。
This document also specifies the messaging and elements of procedure for end-host mobility of a HIP host -- the sequential change in the preferred IP address used to reach a host. In particular, message flows to enable successful host mobility, including address verification methods, are defined herein.
ホストに到達するために使用される好ましいIPアドレスで、順次変更 - この文書はまた、メッセージングとHIPホストのエンドホストモビリティのための手順の要素を指定します。具体的には、メッセージがアドレス検証方法を含む、成功したホストの移動性を可能にするために流れて、本明細書で定義されます。
However, while the same LOCATOR parameter is intended to support host multihoming (parallel support of a number of addresses), and experimentation is encouraged, detailed elements of procedure for host multihoming are left for further study.
同じLOCATORパラメータがホストマルチホーミング（アドレスの数の平行サポート）をサポートするように意図され、そして実験が奨励されている間しかし、ホスト・マルチホーミングのための手順の詳細な要素は、さらなる研究のために残されています。
While HIP can potentially be used with transports other than the ESP transport format [RFC5202], this document largely assumes the use of ESP and leaves other transport formats for further study.
HIPは、潜在的にESPトランスポートフォーマット[RFC5202]以外のトランスポートとともに使用することができるが、この文書は主にESPの使用を想定し、さらなる研究のために他のトランスポートフォーマットを残します。
There are a number of situations where the simple end-to-end readdressing functionality is not sufficient. These include the initial reachability of a mobile host, location privacy, simultaneous mobility of both hosts, and some modes of NAT traversal. In these situations, there is a need for some helper functionality in the network, such as a HIP rendezvous server [RFC5204]. Such functionality is out of the scope of this document. We also do not consider localized mobility management extensions (i.e., mobility management techniques that do not involve directly signaling the correspondent node); this document is concerned with end-to-end mobility. Finally, making underlying IP mobility 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 mobility or multihoming address change, are outside the scope of this document.
シンプルなエンド・ツー・エンドの再アドレッシング機能が十分でない状況がいくつかあります。これらは、最初のモバイルホストの到達可能性、位置プライバシー、両方のホストの同時移動性、およびNATトラバーサルのいくつかのモードがあります。このような状況では、このようなHIPランデブーサーバなどのネットワークにおけるいくつかのヘルパー機能は、[RFC5204]の必要性があります。このような機能は、この文書の範囲外です。また、ローカライズされたモビリティ管理の拡張機能（コレスポンデントノードのシグナリング直接関与しない、すなわち、モビリティ管理技術）を考慮していません。この文書は、エンドツーエンドのモビリティと懸念しています。最後に、トランスポート層への透過的基盤となるIPモビリティを作ることは、トランスポート輻輳制御、パスMTUの選択、およびサービスの品質（QoS）の適切な応答に影響を与えます。トランスポート・レイヤ・モビリティ・トリガ、HIPモビリティやマルチホーミングアドレスの変更への適切な輸送応答は、この文書の範囲外です。
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]に記載されているように解釈されます。
LOCATOR. The name of a HIP parameter containing zero or more Locator fields. This parameter's name is distinguished from the Locator fields embedded within it by the use of all capital letters.
ロケータ。ゼロ以上のロケータフィールドを含むHIPパラメータの名前。このパラメータの名前は、すべて大文字を使用することにより、その中に埋め込まれたロケータフィールドとは区別されます。
Locator. A name that controls how the packet is routed through the network and demultiplexed by the end host. It may include a concatenation of traditional network addresses such as an IPv6 address and end-to-end identifiers such as an ESP SPI. It may also include transport port numbers or IPv6 Flow Labels as demultiplexing context, or it may simply be a network address.
ロケータ。パケットがネットワーク経由でルーティングされ、エンドホストで分波された方法を制御名前。このようなIPv6アドレスとそのようなESP SPIなどのエンドツーエンドの識別子として従来のネットワークアドレスの連結を含むことができます。また、分波コンテキストとして輸送ポート番号またはIPv6フローラベルを含むことができ、またはそれは単にネットワークアドレスであってもよいです。
Address. A name that denotes a point-of-attachment to the network. The two most common examples are an IPv4 address and an IPv6 address. The set of possible addresses is a subset of the set of possible locators.
住所。ネットワークへのポイントオブアタッチメントを示し名。二つの最も一般的な例は、IPv4アドレスとIPv6アドレスです。可能なアドレスのセットが可能なロケータのセットのサブセットです。
Preferred locator. A locator on which a host prefers to receive data. With respect to a given peer, a host always has one active Preferred locator, unless there are no active locators. By default, the locators used in the HIP base exchange are the Preferred locators.
優先ロケータ。ロケータは、どのホストがデータを受信することを好みます。所与のピアに対して、ホストは常にアクティブロケータが存在しない場合を除き、一つの活性優先ロケータを有しています。デフォルトでは、HIPベース交換に使用されるロケータは優先ロケータです。
Credit Based Authorization. A host must verify a mobile or multihomed peer's reachability at a new locator. Credit-Based Authorization authorizes the peer to receive a certain amount of data at the new locator before the result of such verification is known.
クレジットベースの認証。ホストが新しいロケータでモバイルまたはマルチホームピアの到達可能性を検証しなければなりません。クレジットベースの認証は、検証の結果が知られる前に新たなロケータで一定量のデータを受信するためにピアを許可します。
This section is an overview; more detailed specification follows this section.
このセクションでは、概要です。より詳細な仕様は、このセクションの後に続きます。
The Host Identity Protocol (HIP) [RFC5201] is a key establishment and parameter negotiation protocol. Its primary applications are for authenticating host messages based on host identities, and establishing security associations (SAs) for the ESP transport format [RFC5202] and possibly other protocols in the future.
ホストアイデンティティプロトコル（HIP）[RFC5201]キー確立およびパラメータネゴシエーションプロトコルです。その主な用途は、ホストのアイデンティティに基づいてホストメッセージを認証し、将来的にはESPのトランスポートフォーマット[RFC5202]、およびおそらく他のプロトコルのためのセキュリティアソシエーション（SA）を確立するためのものです。
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
Figure 1: HIP Deployment Model
図1：HIPの展開モデル
The general deployment model for HIP is shown above, assuming operation in an end-to-end fashion. This document specifies extensions to the HIP protocol to enable end-host mobility and basic multihoming. In summary, these extensions to the HIP base protocol enable the signaling of new addressing information to the peer in HIP messages. The messages are authenticated via a signature or keyed hash message authentication code (HMAC) based on its Host Identity. This document specifies the format of this new addressing (LOCATOR) parameter, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for a concurrent address verification mechanism.
HIPのための一般的な展開モデルは、エンドツーエンド方式で動作すると仮定すると、上記に示されています。この文書では、エンドホストの移動性と基本的なマルチホーミングを可能にするために、HIPプロトコルに拡張子を指定します。要約すると、HIP基本プロトコルにこれらの拡張は、HIPメッセージ内のピアへの新たなアドレス指定情報のシグナリングを可能にします。メッセージは、ホストアイデンティティに基づく署名や鍵付きハッシュメッセージ認証コード（HMAC）を介して認証されています。この文書では、この新しいアドレッシング（LOCATOR）パラメータ、基本的なホストモビリティを有効にするには、このパラメータを送信し、処理するための手順、および同時アドレス検証メカニズムのための手続の形式を指定します。
---------
| TCP | (sockets bound to HITs)
---------
|
---------
----> | ESP | {HIT_s, HIT_d} <-> SPI
| ---------
| |
---- ---------
| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
---- ---------
|
---------
| IP |
---------
Figure 2: Architecture for HIP Mobility and Multihoming (MH)
図2：HIPモビリティとマルチホーミングのためのアーキテクチャ（MH）
Figure 2 depicts a layered architectural view of a HIP-enabled stack using the ESP transport format. In HIP, upper-layer protocols (including TCP and ESP in this figure) are bound to Host Identity Tags (HITs) and not IP addresses. The HIP sublayer is responsible for maintaining the binding between HITs and IP addresses. The SPI is used to associate an incoming packet with the right HITs. The block labeled "MH" is introduced below.
図2は、ESPのトランスポートフォーマットを使用して、HIP対応スタックの階層アーキテクチャ図を示します。 HIPでは、（この図ではTCPとESPを含む）上位層プロトコルは、アイデンティティタグ（ヒット）といないIPアドレスをホストにバインドされています。 HIPサブレイヤはヒットとIPアドレスの間の結合を維持する責任があります。 SPIは、右のヒット曲で着信パケットを関連付けるために使用されます。 「MH」と表示されたブロックは、以下に紹介されます。
Consider first the case in which there is no mobility or multihoming, as specified in the base protocol specification [RFC5201]. The HIP base exchange establishes the HITs in use between the hosts, the SPIs to use for ESP, and the IP addresses (used in both the HIP signaling packets and ESP data packets). Note that there can only be one such set of bindings in the outbound direction for any given packet, and the only fields used for the binding at the HIP layer are the fields exposed by ESP (the SPI and HITs). For the inbound direction, the SPI is all that is required to find the right host context. ESP rekeying events change the mapping between the HIT pair and SPI, but do not change the IP addresses.
最初の基本プロトコル仕様[RFC5201]で指定されるように、いかなるモビリティ又はマルチホーミングが存在しない場合を考えます。 HIP基本交換は、ホスト、のSPIは、ESPに使用する、および（HIPシグナリングパケットとESPデータパケットの両方で使用される）IPアドレスとの間の使用中のヒットを確立します。のみが任意の所与のパケットの発信方向のバインディングのような一組が存在することに注意してください、そしてHIP層に結合するために使用される唯一のフィールドは、ESP（SPIとHITS）によって露出されたフィールドです。インバウンド方向の場合、SPIは、右のホストコンテキストを見つけるために必要なものすべてです。 ESP鍵の再生成イベントはHITのペアとSPIとの間のマッピングを変更するが、IPアドレスを変更しないでください。
Consider next a mobility event, in which a host is still single-homed but moves to another IP address. Two things must occur in this case. First, the peer must be notified of the address change using a HIP UPDATE message. Second, each host must change its local bindings at the HIP sublayer (new IP addresses). It may be that both the SPIs and IP addresses are changed simultaneously in a single UPDATE; the protocol described herein supports this. However, simultaneous movement of both hosts, notification of transport layer protocols of the path change, and procedures for possibly traversing middleboxes are not covered by this document.
次のホストがまだシングルホームであるが、別のIPアドレスに移動するモビリティ・イベントを、考えてみましょう。二つのことは、この場合に発生する必要があります。まず、ピアはHIP UPDATEメッセージを使用してアドレスの変更を通知しなければなりません。第二に、各ホストは、HIPサブレイヤ（新しいIPアドレス）でそのローカルバインディングを変更する必要があります。これは、のSPIとIPアドレスの両方が単一の更新に同時に変更されることがあってもよいです。本明細書中に記載のプロトコルがこれをサポートしています。しかし、両方のホストの同時移動は、おそらく横断中間装置のためのトランスポート層経路変更のプロトコル、および手順の通知は、この文書で覆われていません。
Finally, consider the case when a host is multihomed (has more than one globally routable address) and has multiple addresses available at the HIP layer as alternative locators for fault tolerance. Examples include the use of (possibly multiple) IPv4 and IPv6 addresses on the same interface, or the use of multiple interfaces attached to different service providers. Such host multihoming generally necessitates that a separate ESP SA is maintained for each interface in order to prevent packets that arrive over different paths from falling outside of the ESP anti-replay window [RFC4303]. Multihoming thus makes it possible that the bindings shown on the right side of Figure 2 are one to many (in the outbound direction, one HIT pair to multiple SPIs, and possibly then to multiple IP addresses). However, only one SPI and address pair can be used for any given packet, so the job of the "MH" block depicted above is to dynamically manipulate these bindings. Beyond locally managing such multiple bindings, the peer-to-peer HIP signaling protocol needs to be flexible enough to define the desired mappings between HITs, SPIs, and addresses, and needs to ensure that UPDATE messages are sent along the right network paths so that any HIP-aware middleboxes can observe the SPIs. This document does not specify the "MH" block, nor does it specify detailed elements of procedure for how to handle various multihoming (perhaps combined with mobility) scenarios. The "MH" block may apply to more general problems outside of HIP. However, this document does describe a basic multihoming case (one host adds one address to its initial address and notifies the peer) and leave more complicated scenarios for experimentation and future documents.
ホストがマルチホームされたときに最後に、ケースを考える（複数のグローバルにルーティング可能なアドレスを持っている）と、フォールトトレランスのための代替ロケータとしてHIP層において利用可能な複数のアドレスを持っています。例としては、同じインターフェイス上で（場合によっては複数）のIPv4およびIPv6アドレスの使用、又は異なるサービスプロバイダに取り付けられた複数のインターフェースの使用を含みます。そのようなホストマルチホーミングは、一般に、別個ESP SAがESPアンチリプレイウィンドウ[RFC4303]の外の異なるパスを介して到着したパケットを防ぐために、各インタフェースのために維持されることを必要とします。マルチホーミングは、このように、図2の右側に示すバインディング（、アウトバウンド方向に複数のSPIに1 HIT対、および場合によっては、複数のIPアドレスに）多くの1つであることができます。しかし、唯一のSPIと宛先のペアは、任意の所与のパケットのために使用することができるので、上に示した「MH」ブロックのジョブは、動的に、これらのバインディングを操作することです。局所的に、このような複数のバインディングを管理超えて、ピア・ツー・ピアHIPシグナリングプロトコルはヒット、のSPI、およびアドレスとの間の所望のマッピングを定義するのに十分に柔軟である必要があり、そのようUPDATEメッセージが正しいネットワーク経路に沿って送信されることを保証する必要があります任意のHIP-意識ミドルボックスは、SPIを観察することができます。この文書では、「MH」ブロックを指定していません。また、（おそらくモビリティと組み合わせて）様々なマルチホーミングシナリオを処理する方法のための手順の詳細な要素を指定しません。 「MH」ブロックは、HIPの外側に、より一般的な問題に適用することができます。ただし、このドキュメントでは、基本的なマルチホーミングケースを記述する（1つのホストは、その最初のアドレスに一つのアドレスを追加し、ピアに通知）と実験と将来の文書のために、より複雑なシナリオを残すん。
This document defines a generalization of an address called a "locator". A locator specifies a point-of-attachment to the network but may also include additional end-to-end tunneling or per-host demultiplexing context that affects how packets are handled below the logical HIP sublayer of the stack. This generalization is useful because IP addresses alone may not be sufficient to describe how packets should be handled below HIP. For example, in a host multihoming context, certain IP addresses may need to be associated with certain ESP SPIs to avoid violating the ESP anti-replay window. Addresses may also be affiliated with transport ports in certain tunneling scenarios. Locators may simply be traditional network addresses. The format of the locator fields in the LOCATOR parameter is defined in Section 4.
この文書は、「ロケータ」と呼ばれるアドレスの一般化を定義します。ロケータは、ネットワークへのポイントオブアタッチメントを指定するだけでなく、追加のエンドツーエンドのトンネリングまたはパケットがスタックの論理HIP副層の下に処理される方法に影響ホストごとの分離・コンテキストを含むことができます。単独のIPアドレスは、パケットはHIPの下に処理する方法を記述するのに十分ではないかもしれないので、この一般化は有用です。例えば、ホストマルチホーミングコンテキストで、特定のIPアドレスがESPアンチリプレイウィンドウに違反避けるために、特定のESPのSPIに関連付けする必要があるかもしれません。アドレスは、特定のトンネリングシナリオにおける輸送ポートと提携することができます。ロケータは、単に従来のネットワークアドレスかもしれません。 LOCATORパラメータのロケータフィールドのフォーマットは、セクション4で定義されています。
When a host moves to another address, it notifies its peer of the new address by sending a HIP UPDATE packet containing a LOCATOR parameter. This UPDATE packet is acknowledged by the peer. For reliability in the presence of packet loss, the UPDATE packet is retransmitted as defined in the HIP protocol specification [RFC5201]. The peer can authenticate the contents of the UPDATE packet based on the signature and keyed hash of the packet.
ホストが別のアドレスに移動すると、それがLOCATORパラメタを含むHIP更新パケットを送信することにより、新しいアドレスのピアに通知します。このUPDATEパケットは、ピアによって認識されています。 HIPプロトコル仕様[RFC5201]で定義されるようにパケット損失の存在下での信頼性のために、更新パケットが再送されます。ピアはパケットの署名と鍵付きハッシュに基づいて、更新パケットの内容を認証することができます。
When using ESP Transport Format [RFC5202], the host may at the same time decide to rekey its security association and possibly generate a new Diffie-Hellman key; all of these actions are triggered by including additional parameters in the UPDATE packet, as defined in the base protocol specification [RFC5201] and ESP extension [RFC5202].
ESPトランスポート・フォーマット[RFC5202]を使用する場合は、ホストが、同時にそのセキュリティアソシエーションをリキー、おそらく新しいDiffie-Hellman鍵を生成することを決定することができます。基本プロトコル仕様[RFC5201]およびESP拡張[RFC5202]で定義されるように、これらの操作の全ては、更新パケット内の追加のパラメータを含むことによってトリガされます。
When using ESP (and possibly other transport modes in the future), the host is able to receive packets that are protected using a HIP created ESP SA from any address. Thus, a host can change its IP address and continue to send packets to its peers without necessarily rekeying. However, the peers are not able to send packets to these new addresses before they can reliably and securely update the set of addresses that they associate with the sending host. Furthermore, mobility may change the path characteristics in such a manner that reordering occurs and packets fall outside the ESP anti-replay window for the SA, thereby requiring rekeying.
ESP（およびおそらく将来的には他のトランスポートモード）を使用する場合、ホストは、任意のアドレスからESP SA作成HIPを使用して保護されたパケットを受信することができます。したがって、ホストは、そのIPアドレスを変更し、必ずしも再入力することなく、そのピアにパケットを送信し続けることができます。しかし、ピアは、彼らが確実かつ安全に、彼らは送信ホストに関連付けるアドレスのセットを更新することができます前に、これらの新しいアドレスにパケットを送信することができません。さらに、移動度がそれによってキー更新を必要とする、並べ替えが発生し、パケットがSAのESPアンチリプレイウィンドウから外れるようにパス特性を変更することができます。
A related operational configuration is host multihoming, in which a host has multiple locators simultaneously rather than sequentially, as in the case of mobility. By using the LOCATOR parameter defined herein, a host can inform its peers of additional (multiple) locators at which it can be reached, and can declare a particular locator as a "preferred" locator. Although this document defines a basic mechanism for multihoming, it does not define detailed policies and procedures, such as which locators to choose when more than one pair is available, the operation of simultaneous mobility and multihoming, source address selection policies (beyond those specified in [RFC3484]), and the implications of multihoming on transport protocols and ESP anti-replay windows. Additional definitions of HIP-based multihoming are expected to be part of future documents.
関連動作の構成は、ホストは、移動度の場合のように、複数のロケータ同時にではなく順番を有する宿主マルチホーミングです。本明細書で定義さLOCATORパラメータを使用して、ホストは、それに到達することができ、「好ましい」ロケータとして特定のロケータを宣言可能な追加の（複数の）ロケータのピアに知らせることができます。この文書は、マルチホーミングのための基本的なメカニズムを定義しているが、それはで指定されたものを超えて（複数の対は、同時モビリティ及びマルチホーミングの動作を利用可能である場合に選択するロケーター例えばれるように、ソースアドレス選択ポリシーの詳細なポリシーおよび手順を定義していません[RFC3484]）、およびトランスポートプロトコルとESPアンチリプレイウィンドウ上でマルチホーミングの意味。 HIPベースのマルチホーミングのさらなる定義は将来の文書の一部であると予想されます。
In this section, we briefly introduce a number of usage scenarios for HIP mobility and multihoming. These scenarios assume that HIP is being used with the ESP transform [RFC5202], 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 [RFC5201]. 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 SPI acts as an index to the right host-to-host context. More specification details are found later in Section 4 and Section 5.
このセクションでは、我々は簡単にHIPモビリティとマルチホーミングのための使用シナリオの数を紹介します。他のシナリオは、将来的に定義することができるが、これらのシナリオは、[RFC5202]変換HIPは、ESPで使用されていると仮定する。これらの使用シナリオを理解するために、読者は、HIPプロトコル仕様[RFC5201]と少なくとも最小限に精通しなければなりません。しかし、（比較的）初心者の読者のために、HIPで、実際のペイロードトラフィックはESPで保護されている心に留めておくために最も重要であり、ESP SPIは、右のホスト間のコンテキストへのインデックスとして機能していること。その他の仕様の詳細は、後に第4節と第5節に記載されています。
The scenarios below assume that the two hosts have completed a single HIP base exchange with each other. Both of the hosts therefore have one incoming and one outgoing SA. Further, each SA uses the same pair of IP addresses, which are the ones used in the base exchange.
以下のシナリオは、2つのホストが相互に単一HIP基本交換を完了していると仮定する。ホストの両方は、従って、入ってくる1つずつ発信SAを有しています。さらに、各SAは、塩基交換に使用されるものであるIPアドレスの同じ組を使用します。
The readdressing protocol is an asymmetric protocol where a mobile or multihomed host informs a peer host about changes of IP addresses on affected SPIs. The readdressing exchange is designed to be piggybacked on existing HIP exchanges. The majority of the packets on which the LOCATOR parameters are expected to be carried are UPDATE packets. However, some implementations may want to experiment with sending LOCATOR parameters also on other packets, such as R1, I2, and NOTIFY.
再アドレス指定プロトコルは、モバイルまたはマルチホームホストが影響を受けるのSPI上のIPアドレスの変更に関するピア・ホストに通知非対称プロトコルです。再アドレス交換は、既存のHIP取引所に便乗するように設計されています。 LOCATORパラメータが実施されることが期待されたパケットの大部分は、更新パケットです。しかし、いくつかの実装は、R1、I2として、他のパケットにもLOCATORパラメータを送信することを試してみたい、と通知してもよいです。
The scenarios below at times 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 below (Section 5.6), an UNVERIFIED address may be used. The addressing states are defined more formally in Section 5.1.
時間に以下のシナリオのいずれか、ACTIVE VERIFIED、または推奨されない状態であるとしてアドレスが記載されています。ホストの観点から、ピアの新たに学習されたアドレスは、前に確認する必要があり、アクティブなサービスの中に入れて、ピアによって除去アドレスは非推奨状態に置かれています。 （セクション5.6）説明限られた条件下で、UNVERIFIEDアドレスを使用することができます。アドレッシング状態はセクション5.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 parameter.
そのHIPハンドシェイクのソースアドレスとしてリンクローカルアドレスを使用するホストは、モバイルピアから到達可能でないかもしれません。このようなホストは、最初の握手やLOCATORパラメータによって、グローバルにルーティング可能なアドレスを提供する必要があります。
A mobile host must sometimes change an IP address bound to an interface. The change of an IP address might be needed due to a change in the advertised IPv6 prefixes on the link, a reconnected PPP link, a new DHCP lease, or an actual movement to another subnet. In order to maintain its communication context, the host must inform its peers about the new IP address. This first example considers the case in which the mobile host has only one interface, IP address, a single pair of SAs (one inbound, one outbound), and no rekeying occurs on the SAs. We also assume that the new IP addresses are within the same address family (IPv4 or IPv6) as the first address. This is the simplest scenario, depicted in Figure 3.
モバイルホストは時々インターフェイスにバインドされたIPアドレスを変更する必要があります。 IPアドレスの変化は、リンク上でアドバタイズされたIPv6プレフィックス、再接続のPPPリンク、新しいDHCPリース、または別のサブネットへの実際の動きの変化に必要になることがあります。その通信コンテキストを維持するために、ホストは、新しいIPアドレスについて同輩に通知しなければなりません。この最初の例では、移動ホストが1つのインタフェースだけ、IPアドレス、SAの単一対（一方インバウンド、アウトバウンド1）を有している場合を考慮し、およびNOリキーは、SASには発生しません。我々はまた、新しいIPアドレスが最初のアドレスと同じアドレスファミリー（IPv4またはIPv6）内にあることを前提としています。これは、図3に示されている、最も単純なシナリオです。
Mobile Host Peer Host
モバイルホストのピアホスト
UPDATE(ESP_INFO, LOCATOR, SEQ)
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 3: Readdress without Rekeying, but with Address Check
図3：鍵の再生成せずに回送が、住所を確認して
The steps of the packet processing are as follows:
次のようにパケット処理の手順は次のとおりです。
1. The mobile host is disconnected from the peer host for a brief period of time while it switches from one IP address to another. Upon obtaining a new IP address, the mobile host sends a LOCATOR parameter to the peer host in an UPDATE message. The UPDATE message also contains an ESP_INFO parameter containing the values of the old and new SPIs for a security association. In this case, the OLD SPI and NEW SPI parameters both are set to the value of the preexisting incoming SPI; this ESP_INFO does not trigger a rekeying event but is instead included for possible parameter-inspecting middleboxes on the path. The LOCATOR parameter contains the new IP address (Locator Type of "1", defined below) and a locator lifetime. The mobile host waits for this UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC5201].
それは別のIPアドレスから切り替えながら1モバイルホストは、時間の短い期間のためのピア・ホストから切断されます。新しいIPアドレスを取得すると、モバイルホストは、UPDATEメッセージでピア・ホストにLOCATORパラメタを送信します。 UPDATEメッセージは、セキュリティアソシエーションに新旧のSPIの値を含むESP_INFOパラメータが含まれています。この場合には、OLD SPIとNEW SPIパラメータの両方は、既存の着信SPIの値に設定されています。このESP_INFOは鍵の変更イベントをトリガしませんが、代わりにパス上の可能なパラメータ検査ミドルボックスのために含まれています。 LOCATORパラメータは、新しいIPアドレス（「1」のロケータタイプ、以下に定義）とロケータ寿命が含まれています。モバイルホストが承認されるには、このUPDATEを待ち、そして必要に応じて基本仕様[RFC5201]で指定されるように、再送します。
2. The peer host receives the UPDATE, validates it, and updates any local bindings between the HIP association and the mobile host's destination address. The peer host MUST perform an address verification by placing a nonce in the ECHO_REQUEST parameter of the UPDATE message sent back to the mobile host. It also includes an ESP_INFO parameter with the OLD SPI and NEW SPI parameters both set to the value of the preexisting incoming SPI, and sends this UPDATE (with piggybacked acknowledgment) to the mobile host at its new address. The peer MAY use the new address immediately, but it MUST limit the amount of data it sends to the address until address verification completes.
2.ピア・ホストは、UPDATEを受信し、それを検証し、HIPアソシエーションとモバイルホストの宛先アドレスとの間の任意のローカルバインディングを更新します。ピア・ホストは、モバイルホストに送り返さUPDATEメッセージのECHO_REQUESTパラメータでnonceを配置することによって、アドレス検証を実行しなければなりません。それはまた、OLD SPIとNEW SPIパラメータ既存の着信SPIの値に設定し、その新しいアドレスでモバイルホストに（ピギーバック肯定応答を伴う）、この更新を送信両方とESP_INFOパラメータを含みます。ピアは、すぐに新しいアドレスを使用するかもしれないが、それはアドレスの検証が完了するまで、それがアドレスに送信するデータの量を制限しなければなりません。
3. The mobile host completes the readdress by processing the UPDATE ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer host receives this ECHO_RESPONSE, it considers the new address to be verified and can put the address into full use.
3.モバイルホストは、UPDATE ACKを処理しECHO_RESPONSEでnonceをエコーによって回送を完了する。ピア・ホストがこのECHO_RESPONSEを受け取ると、それは新しいアドレスを検証すると判断し、完全な使用に住所を置くことができます。
While the peer host is verifying the new address, the new address is marked as UNVERIFIED in the interim, and the old address is DEPRECATED. Once the peer host has received a correct reply to its UPDATE challenge, it marks the new address as ACTIVE and removes the old address.
ピア・ホストが新しいアドレスを確認している間に、新しいアドレスは暫定でUNVERIFIEDとしてマークされ、古いアドレスが推奨されていません。ピア・ホストはそのUPDATEチャレンジに対する正しい応答を受信したら、それはACTIVEとして新しいアドレスをマークし、古いアドレスを削除します。
The mobile host may decide to rekey the SAs at the same time that it notifies the peer of the new address. In this case, the above procedure described in Figure 3 is slightly modified. The UPDATE message sent from the mobile host includes an ESP_INFO with the OLD SPI set to the previous SPI, the NEW SPI set to the desired new SPI value for the incoming SA, and the KEYMAT Index desired. Optionally, the host may include a DIFFIE_HELLMAN parameter for a new Diffie-Hellman key. The peer completes the request for a rekey as is normally done for HIP rekeying, except that the new address is kept as UNVERIFIED until the UPDATE nonce challenge is received as described above. Figure 4 illustrates this scenario.
モバイルホストは、それが新しいアドレスのピアに通知し、同時にSAをリキーすることもできます。この場合、図3で説明した上記の手順は、わずかに修正されます。移動ホストから送信されたUPDATEメッセージは、古いSPIとESP_INFOは前SPI、着信SAのための所望の新しいSPI値に新しいSPIセット、及び所望KEYMATインデックスに設定含みます。必要に応じて、ホストは新しいDiffie-HellmanキーのDIFFIE_HELLMANパラメータを含むことができます。ピアは、通常、上記のようにUPDATEノンスチャレンジが受信されるまで、新しいアドレスはUNVERIFIEDとして維持されることを除いて、HIPのキー更新のために行われているように鍵更新要求を完了する。図4は、このシナリオを示しています。
Mobile Host Peer Host
モバイルホストのピアホスト
UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 4: Readdress with Mobile-Initiated Rekey
図4：モバイル開始リキーと回送
A (mobile or stationary) host may sometimes have more than one interface or global address. The host may notify the peer host of the additional interface or address by using the LOCATOR parameter. To avoid problems with the ESP anti-replay window, a host SHOULD use a different SA for each interface or address used to receive packets from the peer host when multiple locator pairs are being used simultaneously rather than sequentially.
（モバイルまたは固定）ホストは、時には複数のインターフェイスまたはグローバルアドレスを有していてもよいです。ホストは、ロケータパラメータを使用して、追加のインタフェースやアドレスのピア・ホストに通知することができます。 ESPアンチリプレイウィンドウの問題を回避するために、ピア・ホストからパケットを受信するために使用される各インターフェイスまたはアドレスに異なるSAを使用すべきホストは、複数の位置決め対は、同時にではなく連続的に使用されているとき。
When more than one locator is provided to the peer host, the host SHOULD indicate which locator is preferred (the locator on which the host prefers to receive traffic). By default, the addresses used in the base exchange are preferred until indicated otherwise.
複数のロケータがピア・ホストに提供される場合、ホストは好適であるロケータ（ホストがトラフィックを受信することを好むその上Locator）を示すべきです。別段の指示がされるまで、デフォルトでは、塩基交換に使用されるアドレスが好ましいです。
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, although rules for source address selection should ultimately govern the selection of the source locator based on the destination locator.
マルチホーミング場合には、送信者はまた、そこから元トラフィックに複数の有効なロケータを有することができます。ソースアドレス選択のためのルールは最終的に宛先ロケータに基づいて、ソースロケータの選択を支配するべきであるが、実際には、マルチホーミング構成における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 RECOMMENDED 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 be also rekeyed at that time. Although asymmetric SA configurations might be experimented with, their usage may constrain interoperability at this time. However, it is recommended that implementations attempt to support peers that prefer to use non-paired SAs. It is expected that this section and behavior will be modified in future revisions of this protocol, once the issue and its implications are better understood.
プロトコルは、ホスト間のSAの非対称な数が存在する構成を可能にすることができるが、それはそれがインバウンド推奨されている（例えば、ピアは1つのインターフェイスと1つのインバウンドSAを有している、一つのホストは、二つのインターフェース二つインバウンドSAを有する）とアウトバウンドSAは、ホスト間でペアごとに作成されます。 ESP_INFOは、特定の発信SAキーを再生成するために到着すると、対応するインバウンドSAはまた、その時点でリキーしなければなりません。非対称SA構成はで実験するかもしれませんが、それらの使用法は、この時点での相互運用性を制約することがあります。しかし、実装は非ペアリングSAを使用することを好む仲間を支援しようとすることをお勧めします。問題とその意味がよりよく理解されていたら、このセクションや行動が、このプロトコルの将来の改訂で変更されることが期待されます。
Consider the case between two hosts, one single-homed and one multihomed. The multihomed host may decide to inform the single-homed host about its other address. It is RECOMMENDED that the multihomed host set up a new SA pair for use on this new address. To do this, the multihomed host sends a LOCATOR 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 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 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 an 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. Figure 5 illustrates this scenario.
二つのホスト、シングルホーム1および1つのマルチホームの間の場合を考えます。マルチホームホストは他のアドレスについてのシングルホームホストに通知するように決定することができます。マルチホームホストは、この新しいアドレスで使用するための新しいSAのペアを設定することをお薦めします。これを行うには、マルチホームホストはゼロにOLD SPI値を設定して、新しいSA要求を示す、ESP_INFOでLOCATORを送信し、新たに作成され、着信SPIへNEW SPI値。 「1」のロケーター・タイプは、新しいSPIで新しいアドレスを関連付けるために使用されます。 LOCATORパラメータは、元のアドレスとSPIのは、第二のタイプ「1」ロケータを含んでいます。パラメータ処理を簡素化し、ロケータを削除するには、明示的なプロトコル拡張を回避するために、各LOCATORパラメータは、接続で使用中のすべてのロケータ（ホストのインバウンドロケータとのSPIの完全なリスト）をリストする必要があります。マルチホームホストはピアからESP_INFO（新たなアウトバウンドSA）及び独自UPDATEのACKを待ちます。モビリティ場合のように、ピアのホストは、積極的に新しいアドレスを使用する前に、アドレスの検証を実行する必要があります。図5は、このシナリオを示しています。
Multi-homed Host Peer Host
マルチホームホストのピアホスト
UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 5: Basic Multihoming Scenario
図5：基本的なマルチホーミングシナリオ
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 LOCATORs that establish new security associations on an interface with multiple addresses, a host uses the destination address of the UPDATE containing the LOCATOR as the local address to which the LOCATOR 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を運ぶパケットで使用される宛先アドレスを正しくそれらを関連付けることが重要です。複数のアドレスをインターフェイスに新しいセキュリティアソシエーションを確立インバウンドロケータを処理する場合、ホストがLOCATORプラスESP_INFOを標的とするローカルアドレスとしてLOCATORを含むUPDATEの宛先アドレスを使用しています。これは、暗黙的に異なるピア送信元アドレスと提携して、複数のインバウンドSAを作成する効果を持っている - ホストが異なるピアアドレスに同じ（ロケータ）IPアドレスを使用して更新を送信する可能性があるからです。
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 Section 3.2.3. Note that a single interface may experience site multihoming while the host itself may have multiple interfaces.
3.2.3で上述の異なる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 presently specify additional site multihoming extensions to HIP; further alignment with the IETF shim6 working group may be considered in the future.
この文書では、現在、HIPに追加のサイトマルチホーミング拡張子を指定しません。 IETF SHIM6ワーキンググループでさらに整列は、将来的に考えることができます。
Consider the case in which both hosts would like to add an additional address after the base exchange completes. In Figure 6, 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 (containing the address addr1b) to host2, using destination address addr2a, 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; it often may be the case that hosts primarily establish new SAs only with the peer's Preferred locator. The readdressing protocol is flexible enough to accommodate this choice.
両方のホストベースの交換が完了した後に、追加のアドレスを追加したい場合を考えます。図6では、SPI1aとのSpi2Aを設定するために塩基交換でアドレスaddr1aを使用しているhost1のを、検討し、アドレスaddr1bを追加したいです。これは、宛先アドレスaddr2aを使用して、HOST2にロケータとUPDATE（アドレスaddr1bを含む）を送信し、及びのSPIの新しいセットは、ホスト1と2（SPI1b及びSPI2bは、それらを呼び出す - 図示せず）の間に追加されるであろう。次に、関係にaddr2bを追加することを決定host2に検討します。 host2がUPDATEを開始するに向けたホスト1のアドレスのいずれかを選択する必要があります。それはaddr1a、addr1b、またはその両方への更新を開始することもできます。それは両方に送信することを選択した場合、SAのフルメッシュ（4 SAペア）が2つのホスト間で存在するであろう。これは、最も一般的な場合です。それは多くの場合、主にのみピアの優先ロケータに新しい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 6: Dual Multihoming Case in Which Each Host Uses LOCATOR to Add a Second Address
図6：デュアルマルチホーミングケース各ホストがLOCATORを使用するには、第2のアドレスを追加します
It looks likely that in the future, many mobile hosts will 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 other(s) may experience mobility (undergo IP address change).
それはすなわち、複数のモバイルインターフェースを持って、将来的には、多くのモバイルホストが同時にモバイルおよびマルチホームになる可能性が見えます。インターフェイスは、異なるアクセス技術を使用している場合（s）は、いくつかの他は、（IPアドレスの変更を受けて）モビリティが発生する可能性がありながら、さらに、（現在のIPアドレスを保持している）インターフェイスの1つが安定現れることがかなりありそうです。
The use of LOCATOR plus ESP_INFO should be flexible enough to handle most such scenarios, although more complicated scenarios have not been studied so far.
より複雑なシナリオは、これまで研究されていないが、LOCATORプラスESP_INFOの使用は、ほとんどのようなシナリオを処理するのに十分に柔軟であるべきです。
It is possible for HIP associations to migrate to a state in which both parties are only using locators in different addressing realms. For example, the two hosts may initiate the HIP association when both are using IPv6 locators, then one host may loose its IPv6 connectivity and obtain an IPv4 address. 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. The basic problem in this example is that the host readdressing to IPv4 does not know a corresponding IPv4 address of the peer. This may be handled (experimentally) by possibly configuring this address information manually or in the DNS, or the hosts exchange both IPv4 and IPv6 addresses in the locator.
HIP団体は、両当事者が異なるだけアドレス範囲にロケータを使用している状態に移行することが可能です。例えば、2つのホストが、両方がIPv6ロケータを使用しているHIPアソシエーションを開始してもよいし、一つのホストは、IPv6接続を失うと、IPv4アドレスを取得してもよいです。このような場合には、異なるレルム間のインターワーキングのための機構のいくつかのタイプが使用されなければなりません。このような技術は、本テキストの範囲外です。この例では基本的な問題は、IPv4に再アドレス、ホストがピアの対応するIPv4のアドレスを知らないということです。これは、おそらく手動で、またはDNSは、このアドレス情報を設定することによって（実験的に）処理することができる、またはホストは、ロケータにIPv4およびIPv6アドレスの両方を交換します。
It is expected that IPv6 networks will be renumbered much more often than most IPv4 networks. From an end-host point of view, network renumbering is similar to mobility.
IPv6ネットワークは、はるかに頻繁にほとんどのIPv4ネットワークよりも番号が付け直されることが期待されます。ビューのエンドホストの観点から、ネットワークのリナンバリングは、モビリティに似ています。
A Responder host MAY include a LOCATOR 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 parameters with a new Preferred locator, the Initiator SHOULD directly set the new Preferred locator to status ACTIVE without performing address verification first, and 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.
レスポンダのホストは、それがイニシエータに送信R1パケットでLOCATORパラメタを含むかもしれません。このパラメータは、R1の署名により保護されなければなりません。 R1パケットが新しい優先ロケータでLOCATORパラメータが含まれている場合、イニシエータは、直接、第1のアドレス検証を行うことなく、ACTIVE状態に新しい優先ロケータを設定する必要があり、新しい優先ロケータにI2パケットを送らなければなりません。 I1の宛先アドレスと新しい優先ロケータは同一であってもよいです。塩基交換が完了すると、すべての新しい非優先ロケータはまだアドレス検証を受けなければなりません。
Initiator Responder
イニシエータレスポンダ
R1 with LOCATOR
<-----------------------------------
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 7: LOCATOR Inclusion in R1
図7：R1でLOCATORのインクルージョン
An Initiator MAY include one or more LOCATOR parameters in the I2 packet, independent of whether or not there was a LOCATOR parameter in the R1. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR parameters, the Responder MUST still send the R2 packet to the source address of the I2. The new
イニシエータは、R1でLOCATORパラメータがあったかどうかとは無関係にI2パケット内の1つまたは複数のLOCATORパラメータを含むことができます。これらのパラメータは、I2署名によって保護されなければなりません。 I2パケットがLOCATORパラメータが含まれている場合でも、ResponderはまだI2の送信元アドレスにR2のパケットを送らなければなりません。新しい
Preferred locator SHOULD be identical to the I2 source address. If the I2 packet contains LOCATOR parameters, all new locators must undergo address verification as usual, and the ESP traffic that subsequently follows should use the Preferred locator.
好適なロケータは、I2の送信元アドレスと同一である必要があります。 I2パケットがLOCATORパラメータが含まれている場合は、すべての新しいロケータは、いつものように、アドレスの確認を受けなければならないし、続いて次のESPトラフィックが優先ロケータを使用する必要があります。
Initiator Responder
イニシエータレスポンダ
I2 with LOCATOR
----------------------------------->
(process normally)
record additional addresses
R2 sent to source address of I2
<-----------------------------------
(process normally)
Figure 8: LOCATOR Inclusion in I2
図8：I2でLOCATORのインクルージョン
The I1 and I2 may be arriving from different source addresses if the LOCATOR 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 [RFC5201]. As a solution, the Responder's puzzle indexing mechanism must be flexible enough to accommodate the situation when R1 includes a LOCATOR parameter.
LOCATORパラメータがR1中に存在する場合I1及びI2は、異なる送信元アドレスから到達することができます。この場合、同時にイニシエータIPアドレスによってインデックスさ複数の事前作成のR1を使用して実装は、不注意による知覚パズルミスマッチにI2パケットのパズル溶液を失敗することがあります。例えば、[RFC5201]の付録Aの例を参照してください。解決策としては、レスポンダのパズルインデックス機構は、R1がLOCATORパラメータが含まれている場合、状況に対応するために十分に柔軟でなければなりません。
When a HIP host receives a set of locators from another HIP host in a LOCATOR, it does not necessarily know whether the other host is actually reachable at the claimed addresses. In fact, a malicious peer host may be intentionally giving bogus addresses in order to cause a packet flood towards the target addresses [RFC4225]. Likewise, viral software may have compromised the peer host, programming it to redirect packets to the target addresses. Thus, the HIP host must first check that the peer is reachable at the new address.
HIPホストがLOCATOR内の別のHIPホストからロケータのセットを受け取ると、それは必ずしも、他のホストが主張アドレスで実際に到達可能であるかどうか分かりません。実際には、悪意あるピアのホストが意図的にターゲットアドレス[RFC4225]へのパケットの洪水を引き起こすために偽のアドレスを与えることができます。同様に、ウイルスソフトウェアは、ターゲットアドレスにパケットをリダイレクトするためにそれをプログラミングする、ピアのホストを侵害している可能性があります。このように、HIPホストは最初のピアが新しいアドレスに到達可能であることを確認する必要があります。
An additional potential benefit of performing address verification is to allow middleboxes in the network along the new path to obtain the peer host's inbound SPI.
アドレス検証を実行する追加の潜在的な利点は、新しいパスに沿って、ネットワーク内のミドルボックスは、相手ホストのインバウンドSPIを得ることができるようにすることです。
Address verification is implemented by the challenger sending some piece of unguessable information to the new address, and waiting for some acknowledgment from the Responder that indicates reception of the information at the new address. This may include the exchange of a nonce, or the generation of a new SPI and observation of data arriving on the new SPI.
アドレス検証は、新しいアドレスに推測できない情報の一部作品を送って、新しいアドレスでの情報の受信を示しレスポンダからいくつかの肯定応答を待っている挑戦者によって実装されます。これは、ナンスの交換、または新規SPIの世代と新しいSPIに到着するデータの観測を含むことができます。
Credit-Based Authorization (CBA) allows a host to securely use a new locator even though the peer's reachability at the address embedded in the locator has not yet been verified. This is accomplished based on the following three hypotheses:
クレジットベースの認証（CBA）は、ホストがしっかりロケータに埋め込まれたアドレスのピアの到達可能性はまだ検証されていないにもかかわらず、新しいロケータを使用することができます。これは、次の3つの仮説に基づいて行われます。
1. A flooding attacker typically seeks to somehow multiply the packets it generates for the purpose of its attack because bandwidth is an ample resource for many victims.
1.フラッディング攻撃者は、通常、何らかの形で、帯域幅は、多くの被災者のための十分なリソースであるので、それはその攻撃の目的のために生成したパケットを乗算することを目指しています。
2. An attacker can often cause unamplified flooding by sending packets to its victim, either by directly addressing the victim in the packets, or by guiding the packets along a specific path by means of an IPv6 Routing header, if Routing headers are not filtered by firewalls.
2.攻撃者はしばしば、直接パケットで被害者に対処することによって、又はルーティングヘッダをによってフィルタリングされていない場合、IPv6ルーティングヘッダにより特定のパスに沿ってパケットを案内することによって、その犠牲者にパケットを送信することによって増幅されていないフラッディングを引き起こすことができますファイアウォール。
3. Consequently, the additional effort required to set up a redirection-based flooding attack (without CBA and return routability checks) would pay off for the attacker only if amplification could be obtained this way.
3.その結果、（CBAなしとルータビリティチェックを返す）リダイレクションベースのフラッディング攻撃を設定するために必要な追加の努力は増幅がこの方法を得ることができた場合にのみ、攻撃者のためにオフに支払うことになります。
On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents amplifications. This is accomplished by limiting the data a host can send to an unverified address of a peer by the data recently received from that peer. Redirection-based flooding attacks thus become less attractive than, for example, pure direct flooding, where the attacker itself sends bogus packets to the victim.
これに基づき、むしろ最初の場所で悪意のあるパケットリダイレクションを排除するよりも、クレジットベース認証は、増幅を防ぐことができます。これは、ホストが最近、そのピアから受信したデータによって、ピアの未検証のアドレスに送信できるデータを制限することによって達成されます。リダイレクションベースのフラッディング攻撃ので、攻撃者自身が被害者に偽のパケットを送信例えば、純粋なダイレクト氾濫、より少ない魅力的になります。
Figure 9 illustrates Credit-Based Authorization: Host B measures the amount of data recently received from peer A and, when A readdresses, sends packets to A's new, unverified address as long as the sum of the packet sizes does not exceed the measured, received data volume. When insufficient credit is left, B stops sending further packets to A until A's address becomes ACTIVE. The address changes may be due to mobility, multihoming, or any other reason. Not shown in Figure 9 are the results of credit aging (Section 5.6.2), a mechanism used to dampen possible time-shifting attacks.
図9は、クレジットベースの認証を示しています。ホストBが、最近、ピアAから受信したデータと、回送の量を測定する測定、受信したを超えていないパケットサイズの合計限り、Aの新しい、未検証のアドレスにパケットを送信しますデータボリューム。不十分なクレジットが残っている場合には、BはAのアドレスがアクティブになるまでAへの更なるパケットの送信を停止します。アドレスの変更は、モビリティ、マルチホーミング、またはその他の理由に起因する可能性があります。図9には示されていないクレジット老化（セクション5.6.2）の結果は、可能なタイムシフト攻撃を減衰するために使用されるメカニズムです。
+-------+ +-------+
| A | | B |
+-------+ +-------+
| |
address |------------------------------->| credit += size(packet)
ACTIVE | |
|------------------------------->| credit += size(packet)
|<-------------------------------| do not change credit
| |
+ address change |
+ address verification starts |
address |<-------------------------------| credit -= size(packet)
UNVERIFIED |------------------------------->| credit += size(packet)
|<-------------------------------| credit -= size(packet)
| |
|<-------------------------------| credit -= size(packet)
| X credit < size(packet)
| | => do not send packet!
+ address verification concludes |
address | |
ACTIVE |<-------------------------------| do not change credit
| |
Figure 9: Readdressing Scenario
図9：再アドレッシングシナリオ
When a host has multiple locators, the peer host must decide which to use for outbound packets. It may be that a host would prefer to receive data on a particular inbound interface. HIP allows a particular locator to be designated as a Preferred locator and communicated to the peer (see Section 4).
ホストが複数のロケータを持っている場合は、ピアのホストが発信するパケットに使用するかを決定しなければなりません。これは、ホストが特定の着信インターフェイス上のデータを受信することを好むだろうということがあります。 HIPは、特定のロケータが好ましいロケータとして指定されたピア（セクション4を参照）に伝達されることを可能にします。
In general, when multiple locators are used for a session, there is the question of using multiple locators for failover only or for load-balancing. Due to the implications of load-balancing on the transport layer that still need to be worked out, this document assumes that multiple locators are used primarily for failover. An implementation may use ICMP interactions, reachability checks, or other means to detect the failure of a locator.
一般的には、複数のロケータがセッションのために使用されている場合、フェイルオーバーのみ、または負荷分散のためのために複数のロケータを使用しての疑問があります。原因はまだ働いする必要があるトランスポート層の負荷分散の意味合いに、このドキュメントでは、複数のロケータは、主にフェイルオーバーに使用されていることを前提としています。実装は、ロケータの故障を検出するICMP相互作用、到達可能性をチェックし、または他の手段を使用してもよいです。
This document specifies a new HIP protocol parameter, the LOCATOR parameter (see Section 4), that allows the hosts to exchange information about their locator(s) and any changes in their locator(s). The logical structure created with LOCATOR parameters has three levels: hosts, Security Associations (SAs) indexed by Security Parameter Indices (SPIs), and addresses.
この文書は、新しいHIPプロトコルパラメータを指定し、LOCATORパラメタ（セクション4を参照）、それはホストが自分のロケータ（S）とそのロケータ（S）の変更についての情報を交換することができます。セキュリティパラメータインデックス（SPIの）、及びアドレスによって索引付けホスト、セキュリティアソシエーション（SA）：LOCATORパラメータで作成された論理構造は三つのレベルを有します。
The relation between these levels for an association constructed as defined in the base specification [RFC5201] and ESP transform [RFC5202] is illustrated in Figure 10.
基本仕様[RFC5201]で定義されており、ESP [RFC5202]を変換するように構成された関連付けのためのこれらのレベルの間の関係は、図10に示されています。
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
Figure 10: Relation between Hosts, SPIs,
and Addresses (Base Specification)
In Figure 10, host1 and host2 negotiate two unidirectional SAs, and each host selects the SPI value for its inbound SA. The addresses addr1a and addr2a are the source addresses that the hosts use in the base HIP exchange. These are the "preferred" (and only) addresses conveyed to the peer for use on each SA. That is, although packets sent to any of the hosts' interfaces may be accepted on the inbound SA, the peer host in general knows of only the single destination address learned in the base exchange (e.g., for host1, it sends a packet on SPI2a to addr2a to reach host2), unless other mechanisms exist to learn of new addresses.
図10に、HOST1とHOST2は、2つの単方向SAをネゴシエートし、各ホストは、そのインバウンドSAのSPI値を選択します。アドレスaddr1aとaddr2aは、ホストが、ベースHIP交換で使用するソースアドレスです。これらは、「好ましい」（のみ）アドレスは各SAで使用するためにピアに搬送されます。ホストのインターフェイスのいずれかに送信されたパケットは、着信SAで受け入れてもよいすなわち、一般にピア・ホストが塩基交換で学習単一の宛先アドレスを知っている（例えば、HOST1のために、それはのSpi2Aにパケットを送信します他のメカニズムは、新しいアドレスを知るために存在していない限り、）ホスト2に到達するためにaddr2aします。
In general, the bindings that exist in an implementation corresponding to this document can be depicted as shown in Figure 11. In this figure, a host can have multiple inbound SPIs (and, not shown, multiple outbound SPIs) associated with another host. Furthermore, each SPI may have multiple addresses associated with it. These addresses that are bound to an SPI are not used to lookup the incoming SA. Rather, the addresses are those that are provided to the peer host, as hints for which addresses to use to reach the host on that SPI. The LOCATOR parameter is used to change the set of addresses that a peer associates with a particular SPI.
この図において、図11に示すように、一般的に、この文書に対応する実装に存在するバインディングを描くことができ、ホストが別のホストに関連付けられた複数のインバウンドのSPI（及び、図示していない、複数のアウトバウンドのSPI）を有することができます。また、各SPIは、それに関連付けられた複数のアドレスを有していてもよいです。 SPIにバインドされているこれらのアドレスは、着信SAをルックアップするために使用されていません。むしろ、アドレスはそのSPI上のホストに到達するために使用するためにどのアドレスのためのヒントとして、ピア・ホストに提供されるものです。 LOCATORパラメータは特定のSPIとのピア会合アドレスのセットを変更するために使用されます。
address11
/
SPI1 - address12
/
/ address21
host -- SPI2 <
\ address22
\
SPI3 - address31
\
address32
Figure 11: Relation between Hosts, SPIs, and Addresses (General Case)
図11：ホスト、SPIの、とアドレスの関係（一般的なケース）
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. For example, if the host needs to change its addresses on SPI2, it is likely that both address21 and address22 will simultaneously become obsolete. In a typical case, such SPIs may correspond with physical interfaces; see below. Note, however, that especially in the case of site multihoming, one of the addresses may become unreachable while the other one still works. In the typical case, however, this does not require the host to inform its peers about the situation, since even the non-working address still logically exists.
ホストがピアとのセキュリティアソシエーション（またはSPIの）任意の数を確立することができます。ピアで複数のSPIを持つことの主な目的は、アドレス運命共有を経験する可能性が高いコレクションにグループ化されます。ホストはSPI2にそのアドレスを変更する必要がある場合、address21とaddress22の両方が同時に陳腐化する可能性があります。典型的なケースでは、そのようなSPIの物理インターフェースに対応することができます。下記参照。もう一つは、まだ動作している間、特にサイトマルチホーミングの場合には、アドレスのいずれかが到達不能になっていること、しかし、注意してください。典型的なケースでは、しかし、これも、非稼働アドレスがまだ論理的に存在するため、状況について同輩に知らせるためにホストを必要としません。
A basic property of HIP SAs is that the inbound IP address is not used to lookup the incoming SA. Therefore, in Figure 11, it may seem unnecessary for address31, for example, to be associated only with SPI3 -- in practice, a packet may arrive to SPI1 via destination address address31 as well. 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 loose.
HIP SAの基本的な性質は、インバウンドIPアドレスが着信SAをルックアップするために使用されていないということです。したがって、図11には、address31に不要に思えるかもしれません、例えば、SPI3のみ関連する - 実際には、パケットは、同様に、宛先アドレスaddress31介しSPI1に到着することができます。しかしながら、異なる送信元アドレスと宛先アドレスの使用は、典型的には、ネットワーク内の異なるレイテンシと、異なる経路をもたらし、パケットは、異なる待ち時間に与えSPI、並べ替えのための任意の宛先IPアドレス（またはパス）を介して到着した場合一部のパケットがESPアンチリプレイウィンドウの外に落下する恐れがあります。アンチリプレイウィンドウに違反するかもしれないという懸念がある場合には、このような理由から、HIPは、インバウンドのSPIでアフィリエイト宛先アドレスへのメカニズムを提供します。この意味で、我々は与えられたインバウンドSPIは、特定のインバウンドIPアドレスの「親和性」を持っており、この親和性は、ピア・ホストに通知されると言うことができます。 ESPアンチリプレイウィンドウが緩んでない限り、各物理インターフェイスは、別々のSAを持っているべきです。
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に送信する場合、ホストは、一貫して同じソースインタフェースを使用して対処すべきです。このため、ホストはそれが役に立つのSPIを変更したり、少なくとも時にピア・ホスト回送そのESPアンチリプレイウィンドウをリセットするかもしれません。
An address may appear on more than one SPI. This creates no ambiguity since the receiver will ignore the IP addresses during SA lookup anyway. However, this document does not specify such cases.
アドレスは、複数のSPIに表示されることがあります。これは、受信機は、とにかくSAルックアップ中にIPアドレスを無視しますので、何のあいまいさを作成しません。しかし、この文書では、このような例が指定されていません。
When the LOCATOR parameter is sent in an UPDATE packet, then the receiver will respond with an UPDATE acknowledgment. When the LOCATOR parameter is sent in an R1 or I2 packet, the base exchange retransmission mechanism will confirm its successful delivery. LOCATORs may experimentally be used in NOTIFY packets; in this case, the recipient MUST consider the LOCATOR as informational and not immediately change the current preferred address, but can test the additional locators when the need arises. The use of the LOCATOR in a NOTIFY message may not be compatible with middleboxes.
LOCATORパラメータがUPDATEパケットで送信された場合、受信機はUPDATE確認応答で応答します。 LOCATORパラメータはR1かI2パケットで送信されると、塩基交換再送メカニズムは、その成功の配信を確認します。ロケータは、実験的にパケットをNOTIFYに使用することができます。この場合には、受信者は情報としてLOCATORを考慮しなければならないし、すぐに現在の優先アドレスを変更しますが、必要が生じた場合に、追加ロケータをテストすることができません。 NOTIFYメッセージでLOCATORの使用は、中間装置と互換性がないかもしれません。
The LOCATOR parameter is a critical parameter as defined by [RFC5201]. It consists of the standard HIP parameter Type and Length fields, plus zero or more Locator sub-parameters. Each Locator sub-parameter contains a Traffic Type, Locator Type, Locator Length, Preferred locator bit, Locator Lifetime, and a Locator encoding. A LOCATOR containing zero Locator fields is permitted but has the effect of deprecating all addresses.
[RFC5201]で定義されるようにLOCATORパラメータは重要なパラメータです。これは、標準のHIPパラメータ・タイプと長さフィールド、プラスゼロ以上のロケータのサブパラメータで構成されています。各ロケータサブパラメータは、トラフィックタイプ、ロケータタイプ、ロケータの長さ、優先ロケータビット、ロケータ寿命、及びロケータ符号化を含んでいます。ゼロロケータフィールドを含むロケータは許可が、すべてのアドレスを非推奨の効果を有しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: LOCATOR Parameter Format
図12：LOCATORパラメータ書式
Type: 193
タイプ：193
Length: Length in octets, excluding Type and Length fields, and excluding padding.
長さ：オクテット、タイプと長さフィールドを除いて、パディングを除いた長さ。
Traffic Type: Defines whether the locator pertains to HIP signaling, user data, or both.
トラフィックタイプは：ロケータはHIPシグナリング、ユーザ・データ、またはその両方に関連するかどうかを定義します。
Locator Type: Defines the semantics of the Locator field.
ロケータタイプ：ロケータフィールドのセマンティクスを定義します。
Locator Length: Defines the length of the Locator field, in units of 4-byte words (Locators up to a maximum of 4*255 octets are supported).
ロケータ長さ：4バイトワード（4つの* 255オクテットの最大ロケータアップがサポートされている）の単位で、ロケータフィールドの長さを定義します。
Reserved: Zero when sent, ignored when received.
予約：ゼロが送信されたときに受け取ったとき、無視されます。
P: Preferred locator. Set to one if the locator is preferred for that Traffic Type; otherwise, set to zero.
P：優先ロケータ。ロケータは、そのトラフィックタイプのために好まれている場合1に設定します。そうでない場合は、ゼロに設定。
Locator Lifetime: Locator lifetime, in seconds.
ロケータ寿命：ロケータの寿命（秒）。
Locator: The locator whose semantics and encoding are indicated by the Locator Type field. All Locator sub-fields are integral multiples of four octets in length.
ロケータ：その意味とエンコーディングロケータTypeフィールドで示されたロケータ。すべてのロケータのサブフィールドの長さは4つのオクテットの整数倍です。
The Locator Lifetime indicates how long the following locator is expected to be valid. The lifetime is expressed in seconds. Each locator MUST have a non-zero lifetime. The address is expected to become deprecated when the specified number of seconds has passed since the reception of the message. A deprecated address SHOULD NOT be used as a destination address if an alternate (non-deprecated) is available and has sufficient scope.
ロケータ寿命は、次のロケータが有効であると期待されている期間を示します。寿命は秒単位で表されます。各ロケータは、非ゼロの寿命を持っていなければなりません。アドレスが指定した秒数がメッセージの受信経過したとき、非推奨となることが期待されます。 （非廃止予定の）代替が利用可能であると十分な範囲を有する場合、非推奨アドレスは、宛先アドレスとして使用することはできません。
The following Traffic Type values are defined:
次のトラフィックタイプの値が定義されています。
0: Both signaling (HIP control packets) and user data.
0：シグナリング（HIP制御パケット）とユーザデータの両方。
1: Signaling packets only.
1：パケットだけをシグナリング。
2: Data packets only.
2：データパケットのみ。
The "P" bit, when set, has scope over the corresponding Traffic Type. That is, when a "P" bit is set for Traffic Type "2", for example, it means that the locator is preferred for data packets. If there is a conflict (for example, if the "P" bit is set for an address of Type "0" and a different address of Type "2"), the more specific Traffic Type rule applies (in this case, "2"). By default, the IP addresses used in the base exchange are Preferred locators for both signaling and user data, unless a new Preferred locator supersedes them. If no locators are indicated as preferred for a given Traffic Type, the implementation may use an arbitrary locator from the set of active locators.
「P」ビット、セットは、対応するトラフィックタイプ上範囲を有しています。すなわち、「P」ビットはトラフィックタイプ用に設定されている場合、「2」は、例えば、ロケータは、データパケットのために好適であることを意味しています。競合がある場合（たとえば、「P」ビットがタイプ「0」のアドレス「2」タイプの異なるアドレスに設定されている場合）、この場合には、より多くの特定のトラフィックタイプのルールが適用される（「2 「）。新しい優先ロケータがそれらを優先しない限り、デフォルトでは、ベース交換に使用されるIPアドレスは、シグナリングとユーザーの両方のデータのためのロケータを優先しています。所与のトラフィックタイプのための好ましいものとして何らロケータが表示されていない場合、実装は、アクティブロケータのセットから任意のロケータを使用してもよいです。
The following Locator Type values are defined, along with the associated semantics of the Locator field:
以下ロケータタイプ値は、ロケータフィールドの関連した意味論と共に、定義されます。
0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] (128 bits long). This locator type is defined primarily for non-ESP-based usage.
0：IPv6アドレスまたはIPv4インのIPv6形式のIPv4アドレス[RFC4291]（128ビット長）。このロケータタイプは、主に非ESPベースの使用のために定義されています。
1: The concatenation of an ESP SPI (first 32 bits) followed by an IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 128 bits). This IP address is defined primarily for ESP-based usage.
1：IPv6アドレスまたはIPv4インのIPv6形式のIPv4アドレス（付加的な128ビット）に続いESP SPI（最初の32ビット）の連結。このIPアドレスは、ESPベースの使用のために主に定義されています。
A number of combinations of parameters in an UPDATE packet are possible (e.g., see Section 3.2). In this document, procedures are defined only for the case in which one LOCATOR and one ESP_INFO parameter is used in any HIP packet. Furthermore, the LOCATOR SHOULD list all of the locators that are active on the HIP association (including those on SAs not covered by the ESP_INFO parameter). Any UPDATE packet that includes a LOCATOR parameter SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The relationship between the announced Locators and any ESP_INFO parameters present in the packet is defined in Section 5.2. The sending of multiple LOCATOR and/or ESP_INFO parameters is for further study; receivers may wish to experiment with supporting such a possibility.
更新パケット内のパラメータの組合せの数が可能である（例えば、セクション3.2を参照）。この文書では、手順は、ただ1つのLOCATORと一つESP_INFOパラメータは、任意のHIPパケットで使用される場合のために定義されています。さらに、ロケータは（ESP_INFOパラメータによって覆われていないSAの上のものを含む）HIPアソシエーション上でアクティブになっているロケータの全てをリストする必要があります。 LOCATORパラメータを含む任意のアップデートパケットは、HMACとHIP_SIGNATUREパラメータの両方を含むべきです。発表されたロケータとパケット中に存在する任意のESP_INFOパラメータとの関係は、5.2節で定義されています。複数のLOCATORおよび/またはESP_INFOパラメータの送信は、今後の検討課題です。受信機は、そのような可能性をサポートして実験したいと思うかもしれません。
This section describes rules for sending and receiving the LOCATOR parameter, testing address reachability, and using Credit-Based Authorization (CBA) on UNVERIFIED locators.
このセクションでは、送受信LOCATORパラメータを、アドレスの到達可能性をテストし、そしてUNVERIFIEDロケータにクレジットベースの承認（CBA）を使用するためのルールが記載されています。
In a typical implementation, each outgoing locator is represented by a piece of state that contains the following data:
典型的な実装では、各発信ロケータは、以下のデータが含まれている状態の部分で表されます。
o the actual bit pattern representing the locator,
ロケータを表す実際のビットパターンのO、
o the lifetime (seconds),
寿命（秒）O、
o the status (UNVERIFIED, ACTIVE, DEPRECATED),
ステータス（ACTIVE UNVERIFIED、旧式）O、
o the Traffic Type scope of the locator, and
Oロケータのトラフィックタイプのスコープ、および
o whether the locator is preferred for any particular scope.
ロケータは、任意の特定の範囲に好ましいかどうか、O。
The status is used to track the reachability of the address embedded within the LOCATOR parameter:
ステータスはLOCATORパラメータ内に埋め込まれたアドレスの到達可能性を追跡するために使用されます。
UNVERIFIED indicates that the reachability of the address has not been verified yet,
UNVERIFIEDは、アドレスの到達可能性はまだ検証されていないことを示し、
ACTIVE indicates that the reachability of the address has been verified and the address has not been deprecated,
ACTIVEは、アドレスの到達可能性が確認されているとアドレスは廃止されていないことを示し、
DEPRECATED indicates that the locator lifetime has expired.
非推奨ロケータ寿命が期限切れになったことを示しています。
The following state changes are allowed:
以下の状態の変更が許可されています。
UNVERIFIED to ACTIVE The reachability procedure completes successfully.
ACTIVEに未検証の到達可能性の手順が正常に完了します。
UNVERIFIED to DEPRECATED The locator lifetime expires while the locator is UNVERIFIED.
UNVERIFIEDは、ロケータがUNVERIFIEDている間、ロケータ寿命が満了した非推奨します。
ACTIVE to DEPRECATED The locator lifetime expires while the locator is ACTIVE.
ACTIVEは、ロケータがアクティブである間、ロケータ寿命が満了した非推奨します。
ACTIVE to UNVERIFIED There has been no traffic on the address for some time, and the local policy mandates that the address reachability must be verified again before starting to use it again.
ACTIVE UNVERIFIEDにいくつかの時間のためのアドレスにトラフィック、およびアドレスの到達可能性は再びそれを使用するために開始する前にもう一度確認する必要があり、ローカルポリシーの義務はありませんでした。
DEPRECATED to UNVERIFIED The host receives a new lifetime for the locator.
UNVERIFIEDに非推奨ホストは、ロケータの新しい生涯を受け取ります。
A DEPRECATED address MUST NOT be changed to ACTIVE without first verifying its reachability.
非推奨アドレスは、最初にその到達可能性を検証せずにACTIVEに変更してはいけません。
Note that the state of whether or not a locator is preferred is not necessarily the same as the value of the Preferred bit in the Locator sub-parameter received from the peer. Peers may recommend certain locators to be preferred, but the decision on whether to actually use a locator as a preferred locator is a local decision, possibly influenced by local policy.
ロケータが好ましいか否かの状態が必ずしもピアから受信したロケータのサブパラメータに優先ビットの値と同じではないことに留意されたいです。ピアは、特定のロケータが好まれることをお勧めかもしれませんが、実際には優先ロケータとしてロケータを使用するかどうかの決定は、おそらくローカルポリシーの影響を受けて現地の決定、です。
The decision of when to send LOCATORs is basically a local policy issue. However, it is RECOMMENDED that a host send a LOCATOR whenever it recognizes a change of its IP addresses in use on an active HIP association, and assumes that the change is going to last at least for a few seconds. Rapidly sending LOCATORs that force the peer to change the preferred address SHOULD be avoided.
ロケータを送信するときの決定は、基本的にローカルポリシーの問題です。しかし、アクティブHIP協会に使用中のIPアドレスの変更を認識し、変更は数秒間、少なくとも最後に起こっていることを前提としていたときに、ホストがLOCATORを送信することが推奨されます。急速に好適なアドレスは避けるべき変更するには、ピアを強制ロケータを送信します。
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. The grouping should consider also whether middlebox interaction requires sending the same LOCATOR in separate UPDATEs on different paths. 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. Grouping policy is outside of the scope of this document.
ホストはそのIPアドレスの変更について、そのピアに通知することを決定したときは、グループにどのようなSPIを持つ様々なアドレスを決定する必要があります。グループ分けは、ミドルの相互作用が異なるパス上の個別の更新プログラムと同じLOCATORを送る必要かどうかも検討すべきです。各SPIは、異なるセキュリティアソシエーションに関連付けられているので、グループポリシーは、ESPアンチリプレイ保護の考えに基づいています。典型的なケースでは、単に最良のポリシーであってもよい実際のカーネルレベルの物理的および論理的インターフェースにグルーピングを基づか。ポリシーをグループ化すると、この文書の範囲外です。
Note that the purpose of announcing IP addresses in a LOCATOR is to provide connectivity between the communicating hosts. In most cases, tunnels or virtual interfaces such as IPsec tunnel interfaces or Mobile IP home addresses provide sub-optimal connectivity. Furthermore, it should be possible to replace most tunnels with HIP based "non-tunneling", therefore making most virtual interfaces fairly unnecessary in the future. Therefore, virtual interfaces SHOULD NOT be announced in general. On the other hand, there are clearly situations where tunnels are used for diagnostic and/or testing purposes. In such and other similar cases announcing the IP addresses of virtual interfaces may be appropriate.
LOCATORにIPアドレスを発表の目的は、通信ホスト間の接続性を提供することであることに注意してください。ほとんどの場合、このようなIPsecトンネルインターフェイスまたはモバイルIPホーム・アドレスとしてトンネルまたは仮想インターフェイスは、最適な接続を提供します。さらに、したがって、将来的には、ほとんどの仮想インターフェイスはかなり不必要作り、HIPに基づく「非トンネリング」と、ほとんどのトンネルを交換することが可能でなければなりません。したがって、仮想インターフェイスは、一般的に発表されるべきではありません。一方、トンネルを診断および/または試験目的のために使用されている状況が明らかに存在します。仮想インターフェイスのIPアドレスを発表そのようなおよび他の同様の場合に適切であり得ます。
Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs. 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.
ホストは、ロケータで、ブロードキャストやマルチキャストアドレスを発表してはなりません。リンクローカルアドレスは、このようなピアのIP宛先アドレスもリンクローカルであるときと同じリンク上の隣人であることが知られているピアに発表されるかもしれません。この場合、リンクローカルアドレスの発表は、政策決定です。ホストが別のリンクに移動したときに好ましいロケータとして使用するリンクローカルアドレスは、到達可能性の問題を作成します。そのピアが同じリンク上にあることが知られていない限り、いずれの場合には、リンクローカルアドレスは、ピアに発表されてはなりません。
Once the host has decided on the groups and assignment of addresses to the SPIs, it creates a LOCATOR parameter that serves as a complete representation of the addresses and affiliated SPIs intended for active use. We now describe a few cases introduced in Section 3.2. 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へのアドレスの割り当てを決定したら、それはアクティブな使用を意図したアドレスの完全な表現と提携のSPIとして機能LOCATORパラメータを作成します。私たちは今、セクション3.2で導入されたいくつかの例を説明します。我々は、各ロケータのトラフィックタイプが「0」（トラフィックタイプのための他の値は、データプレーントラフィックからHIP制御プレーンを別の文書に指定されてもよい）に設定されていると仮定する。その他のモビリティとマルチホーミング例が可能であるが、さらなる実験のために残されています。
1. Host mobility with no multihoming and no rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter. The ESP_INFO contains the current value of the SPI in both the OLD SPI and NEW SPI fields. The LOCATOR contains a single Locator with a "Locator Type" of "1";
マルチホーミングなし再入力なし1.ホスト・モビリティ。モバイルホストが単一LOCATORパラメータで単一ESP_INFOを含有する単一の更新を作成します。 ESP_INFO両方OLD SPIとNEW SPIフィールドにSPIの現在の値を含みます。 LOCATORは「1」の「ロケータタイプ」を持つ単一のロケータが含まれています。
the SPI must match that of the ESP_INFO. The Preferred bit
SHOULD be set and the "Locator Lifetime" is set according to
local policy. The UPDATE also contains a SEQ parameter as usual.
This packet is retransmitted as defined in the HIP protocol
specification [RFC5201]. The UPDATE should be sent to the peer's
preferred IP address with an IP source address corresponding to
the address in the LOCATOR parameter.
2. Host mobility with no multihoming but with rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter (with a single address). The ESP_INFO contains the current value of the SPI in the OLD SPI and the new value of the SPI in the NEW SPI, and a KEYMAT Index as selected by local policy. Optionally, the host may choose to initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter. The LOCATOR contains a single Locator with "Locator Type" of "1"; the SPI must match that of the NEW SPI in the ESP_INFO. Otherwise, the steps are identical to the case in which no rekeying is initiated.
無マルチホーミングでなく、キーの再発行2.ホストのモビリティ。モバイルホストは、（単一のアドレスを持つ）単一LOCATORパラメータを持つ単一ESP_INFOを含有する単一の更新を作成します。 ESP_INFOはローカルポリシーによって選択さOLD SPIでSPIとNEW SPIでのSPIの新しい値、およびKEYMAT指数の現在の値が含まれています。必要に応じて、ホストはDIFFIE_HELLMANパラメータを含むことにより、リキーデフィーヘルマンを開始することを選択することができます。 LOCATORは「1」の「ロケータタイプ」を持つ単一のロケータが含まれています。 SPIはESP_INFOにNEW SPIのそれと一致する必要があります。それ以外の場合は、手順には再入力が開始されていない場合と同じです。
3. 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 SHOULD set up a new SA pair between this new address and the preferred 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 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.
3.ホストマルチホーミング（アドレスの追加）。私たちは（以前に）シングルホーム、非モバイルホストに追加のアドレスを追加する単純なケースを説明します。ホストは、この新たなアドレスとピアホストの好適なアドレス間の新しいSAのペアを設定する必要があります。これを行うには、マルチホームホストは、新しいインバウンドSAを作成し、新しいSPIを作成します。発信UPDATEメッセージを、それが「0」のOLD SPIフィールドとESP_INFOパラメータを挿入し、新しいSPIに対応する新たなSPIフィールド、およびローカルポリシーによって選択さKEYMATインデックス。 （SPIはESP_INFOに含まNEW SPIが一致する）関連の元アドレスとSPIがアクティブ、および新しいアドレスと新しいSPIが追加されているホストは、UPDATEメッセージ2タイプ「1」ロケータとLOCATORに追加します。好ましいビットが好ましい2つのロケータのピア・ホストに通知するために、ポリシーに応じて設定されるべきです。 UPDATEはまた、SEQパラメータおよび任意DIFFIE_HELLMANパラメータが含まれ、この新たなアドレスに対してリキー手順に従います。 UPDATEメッセージは新しいロケータに対応する送信元アドレスを持つピアの優先アドレスに送信する必要があります。
The sending of multiple LOCATORs, locators with Locator Type "0", and multiple ESP_INFO parameters is for further study. Note that the inclusion of LOCATOR in an R1 packet requires the use of Type "0" locators since no SAs are set up at that point.
複数のロケータの送信、ロケーター・タイプ「0」、および複数のESP_INFOのパラメータを持つロケータは、今後の検討課題です。 R1パケットでLOCATORを含めることがないSAがその時点で設定されていないので、タイプ「0」ロケータの使用を必要とすることに留意されたいです。
A host SHOULD be prepared to receive a LOCATOR parameter in the following HIP packets: R1, I2, UPDATE, and NOTIFY.
R1、I2、UPDATE、及びNOTIFY：ホストは、次のHIPパケットでLOCATORパラメータを受信するように準備されるべきです。
This document describes sending both ESP_INFO and LOCATOR parameters in an UPDATE. The ESP_INFO parameter is included when there is a need to rekey or key a new SPI, and is otherwise included for the possible benefit of HIP-aware middleboxes. The LOCATOR 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パラメータの両方を送信して説明します。 ESP_INFOパラメータは、新しいSPIをキー更新またはキーする必要がある場合に含まれており、それ以外の場合はHIP-意識ミドルボックスの可能な利益のために含まれています。 LOCATORパラメタは、ホストが作るか、またはHIPの関連付けのためにアクティブに保つことを希望ロケータの完全なマップが含まれています。
In general, the processing of a LOCATOR 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 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.2.
一般的に、LOCATORの処理は、それが含まれるパケットタイプに依存します。ここで、我々はESP_INFOが存在し、単一LOCATORとESP_INFOがUPDATEメッセージで送信された場合のみを説明し、それ以外の場合は、今後の検討課題です。手順は以下のセクション5.2に記載の各ケースをカバーします。
The processing of ESP_INFO and LOCATOR parameters is intended to be modular and support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR parameters. A host SHOULD first process the ESP_INFO before the LOCATOR, 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ロケータパラメータの処理はモジュラーであり、複数のESP_INFO及び/又は複数LOCATORパラメータの包含に将来一般化をサポートすることを意図しています。タイプ「1」ロケータのみ新しいSPIへの参照を含むことになるながらESP_INFOは、既存のSPIにマッピングされた新しいSPI値を含むことができるので、ホストはまず、LOCATOR前ESP_INFOを処理しなければなりません。
When a host receives a validated HIP UPDATE with a LOCATOR 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と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.
OLD SPIが新しいSPIに等しく、両方が既存のSPIに対応する場合1（なしリキー）は、ESP_INFOは無償ではない（中間装置のために提供される）およびNOキー更新は不要です。
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 parameter will reference this new SPI instead of the old SPI.
2.（リキー）OLD SPIは、既存のSPIを示し、NEW SPIが異なる非ゼロ値であり、既存のSAがリキーされており、ホストが対応するSPIと新しいアウトバウンドSAを作成することによって、HIP ESPのリキー手順に従う場合NEW SPI、このSPIにバインドされていないアドレスを持ちます。 LOCATORパラメータのロケータではなく、古い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にバインドされたすべてのロケータは非推奨状態に置かれます。
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 parameter are processed. For each locator listed in the LOCATOR 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パラメータのロケータが処理されます。 LOCATORパラメータにリストされた各ロケータのために、アドレスは、その中に法的ユニキャストまたはエニーキャストアドレスであることを確認してください。これは、アドレスがブロードキャストやマルチキャストアドレスであるはずがありません、です。ホストが自分自身でHIPを実行することを許可することができるので、いくつかの実装は、ローカルホストを示すアドレスを受け入れるかもしれないことに注意してください。
The below assumes that all locators are of Type "1" with a Traffic Type of "0"; other cases are for further study.
以下のすべてのロケータが「0」のトラフィックタイプを持つタイプ「1」であることを想定しています。それ以外の場合は、今後の検討課題です。
For each Type "1" address listed in the LOCATOR 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. Mark all addresses corresponding to the SPI that were NOT listed in the LOCATOR parameter as DEPRECATED.
LOCATORパラメータにリストされた各タイプ「1」のアドレスは、アドレスが既にSPIに結合されているかどうかをホストチェックが示されました。アドレスがすでにバインドされている場合は、その寿命が更新されます。アドレスのステータスが廃止されている場合、ステータスはUNVERIFIEDに変更されます。アドレスがすでにバインドされていない場合は、アドレスが追加され、そのステータスがUNVERIFIEDに設定されています。マーク非推奨としてLOCATORパラメタに記載されていないし、SPIに対応するすべてのアドレスが。
As a result, at the end of processing, the addresses listed in the LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR parameter have a state of DEPRECATED.
その結果、処理の最後に、LOCATORパラメタに記載されているアドレスがUNVERIFIEDの状態またはACTIVEのいずれかを持っている、とLOCATORパラメタに記載されていない古いSA上の任意の古いアドレスは非推奨の状態を持っています。
Once the host has processed the locators, if the LOCATOR 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.5.
LOCATORパラメータは新しい優先ロケータが含まれている場合は、ホストは、ロケータを処理した後は、ホストが優先ロケータの変更を開始すべきです。これは、ホストが最初に関連付けられたアドレスの到達可能性を検証し、そしてのみ次に優先ロケータを変えることを必要とします。セクション5.5を参照してください。
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 parameter.
ホストがサポートされていないロケータタイプのロケータを受信し、そのようなロケータはまた、ピアの好ましいロケータであると宣言された場合、ホストは含む通知データフィールドと、LOCATOR_TYPE_UNSUPPORTEDのNOTIFYメッセージタイプのエラー通知を送信する必要がある場合受信機が処理に失敗したことロケータ（S）。サポートされていないロケータタイプの（非優先）ロケータがLOCATORパラメータに受信される場合にそうでない場合、ホストはエラー通知を送信することができます。
A host MUST verify the reachability of an UNVERIFIED address. The status of a newly learned address MUST initially be set to UNVERIFIED unless the new address is advertised in a R1 packet as a new Preferred locator. A host MAY also want to verify the reachability of an ACTIVE address again after some time, in which case it would set the status of the address to UNVERIFIED and reinitiate address verification.
ホストはUNVERIFIEDアドレスの到達可能性を検証しなければなりません。新しいアドレスは、新しい優先ロケータとしてR1パケットでアドバタイズされていない限り、新たに学習アドレスの状態は、最初UNVERIFIEDに設定しなければなりません。ホストはまた、UNVERIFIEDにアドレスのステータスを設定し、アドレス検証を再開思われる場合には、いくつかの時間後に再びACTIVEアドレスの到達可能性を検証することもできます。
A host typically starts the address-verification procedure by sending a nonce to the new address. For example, when the host is changing its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD be random and the value MAY be copied into an ECHO_REQUEST sent in the rekeying UPDATE. However, if the host is not changing its SPI, it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent to the new address. A host MAY also use other message exchanges as confirmation of the address reachability.
ホストは通常、新しいアドレスにnonceを送信することにより、アドレス検証手順を開始します。ホストがSPIを変更してピアにESP_INFOを送信している場合、例えば、NEW SPI値はランダムであるべきであり、値がリキーUPDATEで送信ECHO_REQUESTにコピーすることができます。ホストがSPIを変更していない場合は、それはまだ新しいアドレスに送信されたUPDATEメッセージでECHO_REQUESTパラメータを使用するかもしれません。ホストは、アドレスの到達可能性の確認として、他のメッセージ交換を使用するかもしれません。
Note that in the case of receiving a LOCATOR in an R1 and replying with an I2 to the new address in the LOCATOR, receiving the corresponding R2 is sufficient proof of reachability for the Responder's preferred address. Since further address verification of such an address can impede the HIP-base exchange, a host MUST NOT separately verify reachability of a new Preferred locator that was received on an R1.
R1でロケータを受信しLOCATORに新しいアドレスをI2と応答した場合に、対応するR2を受信すると、レスポンダの好ましいアドレスの到達可能性の十分な証拠であることに留意されたいです。そのようなアドレスの更なるアドレス検証がHIP塩基交換を妨げることができるので、ホストは別々R1で受信された新しい優先ロケータの到達可能性を確認してはいけません。
In some cases, it MAY be sufficient to use the arrival of data on a newly advertised SA as implicit address reachability verification as depicted in Figure 13, instead of waiting for the confirmation via a HIP packet. In this case, a host advertising a new SPI as part of its address reachability check SHOULD be prepared to receive traffic on the new SA.
いくつかの場合において、代わりにHIPパケットを介して確認を待ってから、図13に示すように、暗黙的なアドレスの到達可能性の検証として新たにアドバタイズSA上のデータの到着を使用するのに十分であり得ます。この場合、そのアドレスの到達性チェックの一環として、新しいSPIを広告するホストが新しいSAでトラフィックを受信するために準備する必要があります。
Mobile host Peer host
モバイルホストのピアホスト
prepare incoming SA
NEW SPI in ESP_INFO (UPDATE)
<-----------------------------------
switch to new outgoing SA
data on new SA
----------------------------------->
mark address ACTIVE
Figure 13: Address Activation Via Use of a New SA
図13：新しいSAの活性化を介して利用住所
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 Section 5.6. Once address verification succeeds, the status of the new Preferred locator changes to ACTIVE.
アドレス検証が新しい優先ロケータの進行中である場合にはそのようなロケータが利用可能な場合、ホストはアドレス検証が完了するまで、通信を継続するために、ACTIVEとして記載されている別のロケータを選択する必要があります。 UNVERIFIED状態の間、あるいは、宿主は、エクステントクレジットベースの許可許可に新しい優先ロケータを使用するかもしれません。クレジットベースの認証は、セクション5.6で説明されています。アドレス検証が成功したら、新しい優先ロケータのステータスが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 parameter that has the "P" bit set.
交通情報やICMPエラーメッセージは、現在使用される好ましいアドレスが到達不能になっている可能性があることを示しているため、ホストは、例えば、異なる理由から好ましいの発信ロケータを変更することもできます。別の理由は、「P」ビットが設定されているLOCATORパラメータを受信することができます。
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.
新しい優先ロケータがACTIVE状態を持っている1.場合は、優先ロケータが変更され、手順が成功します。
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のステータスを持っている場合、ホストは、その到達可能性を検証するために開始します。そのようなロケータが利用可能な場合、アドレスの確認が完了するまでホストはACTIVEとして記載されている別のロケータを使用すべきです。また、ホストは、エクステントクレジットベースの許可許可にもUNVERIFIED状態でも、新しい優先ロケータを使用するかもしれません。アドレス検証が成功したら、新しい優先ロケータ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.ピア・ホストは任意のアドレスに対する選好を示していない場合、ホストはランダムにピアのアクティブなアドレスのいずれかを選ぶまたはポリシーに従って。例えば、好ましいロケータを廃止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.新しい優先ロケータがステータスを推奨していませんし、少なくとも一つの非非推奨アドレスがある場合、ホストは新しい優先ロケータなどの非推奨されないアドレスのいずれかを選択し続けています。選択されたアドレスがUNVERIFIEDある場合は、上記のアドレス検証手順が適用されます。
To prevent redirection-based flooding attacks, the use of a Credit-Based Authorization (CBA) approach is mandatory when a host sends data to an UNVERIFIED locator. The following algorithm meets the security considerations for prevention of amplification and time-shifting attacks. Other forms of credit aging, and other values for the CreditAgingFactor and CreditAgingInterval parameters in particular, are for further study, and so are the advanced CBA techniques specified in [CBA-MIPv6].
ホストはUNVERIFIEDロケータにデータを送信するとき、リダイレクトベースのフラッディング攻撃を防ぐために、クレジットベース認証（CBA）アプローチの使用が必須です。次のアルゴリズムは、増幅およびタイムシフト攻撃の防止のためのセキュリティの考慮事項を満たしています。クレジットの老化、特にCreditAgingFactorとCreditAgingIntervalパラメータの他の値の他の形態には、さらなる研究のためであるので、[CBA-のMIPv6]で指定された高度なCBAの技術です。
A host maintains a "credit counter" for each of its peers. Whenever a packet arrives from a peer, the host SHOULD increase that peer's credit counter by the size of the received packet. When the host has a packet to be sent to the peer, and when the peer's Preferred locator is listed as UNVERIFIED and no alternative locator with status ACTIVE is available, the host checks whether it can send the packet to the UNVERIFIED locator. The packet SHOULD be sent if the value of the credit counter is higher than the size of the outbound packet. If the credit counter is too low, the packet MUST be discarded or buffered until address verification succeeds. When a packet is sent to a peer at an UNVERIFIED locator, the peer's credit counter MUST be reduced by the size of the packet. The peer's credit counter is not affected by packets that the host sends to an ACTIVE locator of that peer.
ホストは、そのピアごとに「クレジットカウンタ」を維持しています。パケットがピアから到着するたびに、ホストは、受信したパケットのサイズによって、そのピアのクレジットカウンタを増やす必要があります。ホストはピアに送信するパケットがある場合、およびピアの優先ロケータはUNVERIFIEDとしてリストアップされている場合、アクティブ状態とは別のロケータは、それがUNVERIFIEDロケータにパケットを送信できるかどうか、ホストチェック利用できません。クレジットカウンタの値がアウトバウンドパケットのサイズよりも大きい場合にパケットが送信されるべきです。クレジットカウンタが低すぎる場合はアドレス検証が成功するまで、パケットは廃棄されるか、またはバッファされなければなりません。パケットがUNVERIFIEDロケータでピアに送信されると、ピアのクレジットカウンタは、パケットのサイズによって減少させなければなりません。ピアのクレジットカウンタは、ホストがそのピアのACTIVEロケータに送信するパケットの影響を受けません。
Figure 14 depicts the actions taken by the host when a packet is received. Figure 15 shows the decision chain in the event a packet is sent.
図14は、パケットを受信したときにホストによって実行されるアクションを示しています。図15は、パケットが送信されるイベントの判定鎖を示します。
Inbound
packet
|
| +----------------+ +---------------+
| | Increase | | Deliver |
+-----> | credit counter |-------------> | packet to |
| by packet size | | application |
+----------------+ +---------------+
Figure 14: Receiving Packets with Credit-Based Authorization
図14：クレジットベースの認証とパケットを受信
Outbound
packet
| _________________
| / \ +---------------+
| / Is the preferred \ No | Send packet |
+-----> | destination address |-------------> | to preferred |
\ UNVERIFIED? / | address |
\_________________/ +---------------+
|
| Yes
|
v
_________________
/ \ +---------------+
/ Does an ACTIVE \ Yes | Send packet |
| destination address |-------------> | to ACTIVE |
\ exist? / | address |
\_________________/ +---------------+
|
| No
|
v
_________________
/ \ +---------------+
/ Credit counter \ No | |
| >= |-------------> | Drop packet |
\ packet size? / | |
\_________________/ +---------------+
|
| Yes
|
v
+---------------+ +---------------+
| Reduce credit | | Send packet |
| counter by |----------------> | to preferred |
| packet size | | address |
+---------------+ +---------------+
Figure 15: Sending Packets with Credit-Based Authorization
図15：クレジットベースの認証とパケットを送信します
A host ensures that the credit counters it maintains for its peers gradually decrease over time. Such "credit aging" prevents a malicious peer from building up credit at a very slow speed and using this, all at once, for a severe burst of redirected packets.
ホストは、そのピアの維持クレジットカウンタが時間とともに徐々に減少することを保証します。このような「信用老化は、」リダイレクトされたパケットの激しいバーストのために、すべてを一度に、非常に遅い速度で信用を構築し、これを使用することから、悪意のあるピアを防ぐことができます。
Credit aging may be implemented by multiplying credit counters with a factor, CreditAgingFactor (a fractional value less than one), in fixed time intervals of CreditAgingInterval length. Choosing appropriate values for CreditAgingFactor and CreditAgingInterval is important to ensure that a host can send packets to an address in state UNVERIFIED even when the peer sends at a lower rate than the host itself. When CreditAgingFactor or CreditAgingInterval are too small, the peer's credit counter might be too low to continue sending packets until address verification concludes.
クレジット老化はCreditAgingInterval長の一定の時間間隔で、CreditAgingFactor（1未満の端数値）、因子とクレジットカウンタを乗算することによって実現されてもよいです。 CreditAgingFactorとCreditAgingIntervalに適切な値を選択すると、ピアはホスト自体よりも低いレートで送信した場合でも、ホストが状態UNVERIFIEDのアドレスにパケットを送信できるようにすることが重要です。 CreditAgingFactorまたはCreditAgingIntervalが小さすぎる場合には、ピアのクレジットカウンタは、アドレス検証が終了するまでパケットを送信し続けることが低すぎる可能性があります。
The parameter values proposed in this document are as follows:
次のようにこの文書で提案したパラメータ値は次のとおりです。
CreditAgingFactor 7/8 CreditAgingInterval 5 seconds
CreditAgingFactor 7/8 CreditAgingInterval 5秒
These parameter values work well when the host transfers a file to the peer via a TCP connection and the end-to-end round-trip time does not exceed 500 milliseconds. Alternative credit-aging algorithms may use other parameter values or different parameters, which may even be dynamically established.
これらのパラメータ値は、ホストがTCP接続と500ミリ秒を超えていないエンドツーエンドの往復時間を経てピアにファイルを転送するときうまく働きます。代替クレジットエージングアルゴリズムは、他のパラメータ値あるいは動的に確立することができる異なるパラメータを使用することができます。
The HIP mobility mechanism provides a secure means of updating a host's IP address via HIP UPDATE packets. Upon receipt, a HIP host cryptographically verifies the sender of an UPDATE, so forging or replaying a HIP UPDATE packet is very difficult (see [RFC5201]). Therefore, security issues reside in other attack domains. The two we consider are malicious redirection of legitimate connections as well as redirection-based flooding attacks using this protocol. This can be broken down into the following:
HIPモビリティメカニズムはHIP更新パケットを介してホストのIPアドレスを更新する安全な手段を提供します。受信すると、HIPホストは、暗号ので鍛造又はHIP更新パケットを再生し、UPDATEの送信者を検証することは非常に困難である（参照[RFC5201]）。そのため、セキュリティの問題は、他の攻撃のドメインに存在します。私たちが考える2は、正当な接続だけでなく、このプロトコルを使用したリダイレクトベースのフラッド攻撃の悪質なリダイレクトされています。これは、次のように分けることができます。
Impersonation attacks
偽装攻撃
- direct conversation with the misled victim
- 誤解被害者と直接会話
- man-in-the-middle attack
- man-in-the-middle攻撃
DoS attacks
DoS攻撃
- flooding attacks (== bandwidth-exhaustion attacks)
- フラッディング攻撃（==帯域枯渇攻撃）
* tool 1: direct flooding
*ツール1：ダイレクト氾濫
* tool 2: flooding by zombies
*ツール2：ゾンビによって洪水
* tool 3: redirection-based flooding
*ツール3：リダイレクションベースの氾濫
- memory-exhaustion attacks
- メモリ枯渇攻撃
- computational-exhaustion attacks
- 計算-枯渇攻撃
We consider these in more detail in the following sections.
私たちは、次のセクションで詳細にこれらを考慮してください。
In Section 6.1 and Section 6.2, we assume that all users are using HIP. In Section 6.3 we consider the security ramifications when we have both HIP and non-HIP users. Security considerations for Credit-Based Authorization are discussed in [SIMPLE-CBA].
6.1節と6.2節では、我々は、すべてのユーザーがHIPを使用していることを前提としています。我々はHIPと非HIPユーザーの両方を持っているとき、6.3節では、セキュリティ上の影響を考慮します。クレジットベースの認証のためのセキュリティ上の考慮事項は、[SIMPLE-CBA]で議論されています。
An attacker wishing to impersonate another host will try to mislead its victim into directly communicating with them, or carry out a man-in-the-middle (MitM) attack between the victim and the victim's desired communication peer. Without mobility support, both attack types are possible only if the attacker resides on the routing path between its victim and the victim's desired communication peer, or if the attacker tricks its victim into initiating the connection over an incorrect routing path (e.g., by acting as a router or using spoofed DNS entries).
別のホストを偽装したい攻撃者が直接彼らとの通信にその犠牲者を誤解させる、または被害者と被害者の所望の通信相手との間にMITM（中間者）攻撃を実行しようとします。モビリティサポートがなければ、両方の攻撃タイプが可能であり、攻撃者がその被害者と被害者の所望の通信相手間のルーティングパス上に存在する場合にのみ、または攻撃者のトリックその犠牲者かのように作用することにより、間違ったルーティングパス（例えば、上の接続を開始するにルータまたは偽装されたDNSエントリを使用して）。
The HIP extensions defined in this specification change the situation in that they introduce an ability to redirect a connection (like IPv6), both before and after establishment. If no precautionary measures are taken, an attacker could misuse the redirection feature to impersonate a victim's peer from any arbitrary location. The authentication and authorization mechanisms of the HIP base exchange [RFC5201] and the signatures in the UPDATE message prevent this attack. Furthermore, ownership of a HIP association is securely linked to a HIP HI/HIT. If an attacker somehow uses a bug in the implementation or weakness in some protocol to redirect a HIP connection, the original owner can always reclaim their connection (they can always prove ownership of the private key associated with their public HI).
この仕様で定義されたHIP拡張は、彼らが成立する前と後の両方、（IPv6のような）接続をリダイレクトする機能を導入し、その中に状況を変えます。何の予防措置がとられていない場合、攻撃者が任意の場所から、被害者のピアを偽装するリダイレクト機能を誤用ことができます。 HIP基本交換[RFC5201]とUPDATEメッセージ内の署名の認証および認可メカニズムは、この攻撃を防ぎます。また、HIPアソシエーションの所有権を確実HIP HI / HITに連結されています。攻撃者が何とかHIP接続をリダイレクトするために、いくつかのプロトコルで実装や弱点のバグを使用している場合は、元の所有者は、常に、（彼らは常に彼らの公共HIに関連した秘密鍵の所有権を証明することができます）の接続を再利用することができます。
MitM attacks are always possible if the attacker is present during the initial HIP base exchange and if the hosts do not authenticate each other's identities. However, once the opportunistic base exchange has taken place, even a MitM cannot steal the HIP connection anymore because it is very difficult for an attacker to create an UPDATE packet (or any HIP packet) that will be accepted as a legitimate update. UPDATE packets use HMAC and are signed. Even when an attacker can snoop packets to obtain the SPI and HIT/HI, they still cannot forge an UPDATE packet without knowledge of the secret keys.
攻撃者は、最初のHIP基本交換中に存在する場合とホストが互いのアイデンティティを認証していない場合のMITM攻撃は常に可能です。日和見塩基交換が行われた後、攻撃者はUPDATEパケット（または任意のHIPパケット）正当な更新として受け入れられる作成することは非常に困難であるため、しかし、さえのMitMはもうHIP接続を盗むことはできません。 UPDATEパケットはHMACを使用して署名されています。攻撃者はSPIを取得するためにパケットをスヌープし、HI / HITができた場合でも、彼らはまだ秘密鍵の知識なしUPDATEパケットを偽造することはできません。
The purpose of a denial-of-service attack is to exhaust some resource of the victim such that the victim ceases to operate correctly. A denial-of-service attack can aim at the victim's network attachment (flooding attack), its memory, or its processing capacity. In a flooding attack, the attacker causes an excessive number of bogus or unwanted packets to be sent to the victim, which fills their available bandwidth. Note that the victim does not necessarily need to be a node; it can also be an entire network. The attack basically functions the same way in either case.
サービス拒否攻撃の目的は、被害者が正しく動作しなくなったように、被害者のいくつかのリソースを排気することです。サービス拒否攻撃は、被害者のネットワーク接続（フラッディング攻撃）、そのメモリ、またはその処理能力を狙うことができます。フラッディング攻撃では、攻撃者は、偽のまたは不要なパケットの過剰な数が彼らの利用可能な帯域幅をいっぱいに被害者に送信されます。被害者は必ずしもノードである必要はないことに注意してください。それはまた、ネットワーク全体することができます。攻撃は基本的にどちらの場合にも同じように機能します。
An effective DoS strategy is distributed denial of service (DDoS). Here, the attacker conventionally distributes some viral software to as many nodes as possible. Under the control of the attacker, the infected nodes, or "zombies", jointly send packets to the victim. With such an 'army', an attacker can take down even very high bandwidth networks/victims.
効果的なDoS攻撃戦略は、サービス拒否（DDoS攻撃）に分配されます。ここでは、攻撃者は、従来から、できるだけ多くのノードにはいくつかのウイルスソフトウェアを配布しています。攻撃者の制御下で、感染したノード、または「ゾンビ」、共同で被害者にパケットを送信します。このような「軍隊」で、攻撃者は、非常に高い帯域幅ネットワーク/犠牲者を降ろすことができます。
With the ability to redirect connections, an attacker could realize a DDoS attack without having to distribute viral code. Here, the attacker initiates a large download from a server, and subsequently redirects this download to its victim. The attacker can repeat this with multiple servers. This threat is mitigated through reachability checks and credit-based authorization. Both strategies do not eliminate flooding attacks per se, but they preclude: (i) their use from a location off the path towards the flooded victim; and (ii) any amplification in the number and size of the redirected packets. As a result, the combination of a reachability check and credit-based authorization lowers a HIP redirection-based flooding attack to the level of a direct flooding attack in which the attacker itself sends the flooding traffic to the victim.
接続をリダイレクトする機能と、攻撃者は、ウイルスのコードを配布することなく、DDoS攻撃を実現することができました。ここでは、攻撃者がサーバーから大規模なダウンロードを開始し、その後、その犠牲者にこのダウンロードをリダイレクトします。攻撃者は、複数のサーバでこれを繰り返すことができます。この脅威は、到達可能性の確認とクレジットベースの承認によって緩和されます。どちらの戦略は、それ自体がフラッディング攻撃を排除していないが、彼らは排除：浸水被害者への道オフの位置から（I）の使用;および（ii）リダイレクトされたパケットの数と大きさで任意の増幅。その結果、到達可能性チェックとクレジットベースの認証の組み合わせは、攻撃者自身が被害者へのフラッディングトラフィックを送信する直接フラッド攻撃のレベルにHIPリダイレクションベースのフラッディング攻撃を低下させます。
We now consider whether or not the proposed extensions to HIP add any new DoS attacks (consideration of DoS attacks using the base HIP exchange and updates is discussed in [RFC5201]). A simple attack is to send many UPDATE packets containing many IP addresses that are not flagged as preferred. The attacker continues to send such packets until the number of IP addresses associated with the attacker's HI crashes the system. Therefore, there SHOULD be a limit to the number of IP addresses that can be associated with any HI. Other forms of memory/computationally exhausting attacks via the HIP UPDATE packet are handled in the base HIP document [RFC5201].
私たちは今、HIPへの提案の拡張機能は、任意の新しいDoS攻撃（DoS攻撃のベースHIP交換を使用した攻撃や更新を考慮は[RFC5201]で議論されている）を追加するかどうかを検討してください。シンプルな攻撃は、好ましいものとしてフラグが設定されていない多くのIPアドレスを含む多くの更新パケットを送信することです。攻撃者は、攻撃者のHIに関連付けられたIPアドレスの数は、システムがクラッシュするまで、このようなパケットを送信し続けます。したがって、任意のHIに関連付けることができるIPアドレスの数に制限があるべきです。メモリ/計算HIP更新パケットを介して攻撃を排気他の形態は、ベースHIP文献[RFC5201]で処理されます。
A central server that has to deal with a large number of mobile clients may consider increasing the SA lifetimes to try to slow down the rate of rekeying UPDATEs or increasing the cookie difficulty to slow down the rate of attack-oriented connections.
更新情報を再入力するか、攻撃志向の接続の割合を遅くするためにクッキーの難易度を増加率を遅くしようとするSAの寿命を増やすことを検討してモバイル、多数のクライアントに対処している中央サーバー。
We now assume an environment with both HIP and non-HIP aware hosts. Four cases exist.
私たちは今、HIPと非HIP意識したホストの両方を持つ環境を前提としています。 4例が存在します。
1. A HIP host redirects its connection onto a non-HIP host. The non-HIP host will drop the reachability packet, so this is not a threat unless the HIP host is a MitM that could somehow respond successfully to the reachability check.
1. HIPホストは、非HIPホストへの接続をリダイレクトします。非HIPホストが到達可能性のパケットをドロップしますので、HIPホストは何とか到達性チェックに正常に応答することができるのMitMでない限り、これは脅威ではありません。
2. A non-HIP host attempts to redirect their connection onto a HIP host. This falls into IPv4 and IPv6 security concerns, which are outside the scope of this document.
2.非HIPホストは、HIPホストへの接続をリダイレクトすることを試みます。これは、この文書の範囲外であるIPv4とIPv6のセキュリティの問題、に分類されます。
3. A non-HIP host attempts to steal a HIP host's session (assume that Secure Neighbor Discovery is not active for the following). The non-HIP host contacts the service that a HIP host has a connection with and then attempts to change its IP address to steal the HIP host's connection. What will happen in this case is implementation dependent but such a request should fail by being ignored or dropped. Even if the attack were successful, the HIP host could reclaim its connection via HIP.
（セキュア近隣探索は、以下のためにアクティブではないと仮定）HIPホストのセッションを盗むために前記非HIPホスト試みます。非HIPホストの連絡先HIPホストはとの接続があり、その後、HIPホストの接続を盗むためにそのIPアドレスを変更しようとするサービス。何この場合にはどうなることは実装依存であるが、そのような要求が無視されるか、または廃棄されることにより、失敗するはずです。攻撃が成功した場合でも、HIPホストはHIP経由での接続を取り戻すことができました。
4. A HIP host attempts to steal a non-HIP host's session. A HIP host could spoof the non-HIP host's IP address during the base exchange or set the non-HIP host's IP address as its preferred address via an UPDATE. Other possibilities exist, but a simple solution is to prevent the use of HIP address check information to influence non-HIP sessions.
4. HIPホストは非HIPホストのセッションを盗むしようとします。 HIPホストは、塩基交換中に非HIPホストのIPアドレスをスプーフィングまたはUPDATEを介してその好ましいアドレスとして非HIPホストのIPアドレスを設定することができました。他の可能性が存在するが、簡単な解決策は、非HIPセッションに影響を与えるHIPアドレスチェック情報の使用を防止するためです。
This document defines a LOCATOR parameter for the Host Identity Protocol [RFC5201]. This parameter is defined in Section 4 with a Type of 193.
この文書では、ホスト識別プロトコル[RFC5201]のためのLOCATORパラメータを定義します。このパラメータは、193のタイプと4節で定義されています。
This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message Type as defined in the Host Identity Protocol specification [RFC5201]. This parameter is defined in Section 5.3 with a value of 46.
この文書はまた、ホストアイデンティティプロトコル仕様[RFC5201]で定義されるようLOCATOR_TYPE_UNSUPPORTEDは、メッセージタイプを通知定義します。このパラメータは、46の値を持つセクション5.3で定義されています。
Pekka Nikander and Jari Arkko originated this document, and Christian Vogt and Thomas Henderson (editor) later joined as co-authors. Greg Perkins contributed the initial draft of the security section. Petri Jokela was a co-author of the initial individual submission.
ペッカNikanderとヤリArkkoはこの文書を発し、そしてクリスチャン・フォークトとトーマス・ヘンダーソン（編集者）は、後に共著者として参加しました。グレッグ・パーキンスは、セキュリティセクションの最初の草案に貢献しました。ペトリJokelaは初期個々の提出の共著者でした。
The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document.
作者はドキュメントに多くの改善のためにMiikaこむ、ミカKousa、ジェフAhrenholz、とJanメレンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the ESP Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202] Jokela、P.、モスコウィッツ、R.、およびP. Nikander、RFC 5202、2008年4月 "ホスト識別プロトコル（HIP）とESPトランスポートフォーマットを使用します"。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] Laganier、J.とL.エッゲルト、 "ホストアイデンティティプロトコル（HIP）ランデブー拡張"、RFC 5204、2008年4月。
[CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", Work in Progress, February 2005.
[CBA-のMIPv6]フォークト、C.とJ. Arkko、 "モバイルIPv6早期のアップデートを結合するためのクレジットベース認証"、進歩、2005年2月に作業。
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4225] Nikander、P.、Arkko、J.、オーラ、T.、モンテネグロ、G.、およびE. Nordmarkと、 "モバイルIPバージョン6経路最適化セキュリティデザインの背景"、RFC 4225、2005年12月。
[SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for Concurrent Reachability Verification", Work in Progress, February 2006.
[SIMPLE-CBA]フォークト、C.とJ. Arkko、 "同時到達可能性検証のためのクレジットベース認証"、進歩、2006年2月に作業。
Authors' Addresses
著者のアドレス
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペッカNikanderエリクソン研究NomadicLab JORVAS FIN-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
電話：+358 9 299 1 Eメール：pekka.nikander@nomadiclab.com
Thomas R. Henderson (editor) The Boeing Company P.O. Box 3707 Seattle, WA USA
トーマス・R.ヘンダーソン（エディタ）ボーイング社の私書箱ボックス3707シアトル、WA USA
EMail: thomas.r.henderson@boeing.com
メールアドレス：thomas.r.henderson@boeing.com
Christian Vogt Ericsson Research NomadicLab Hirsalantie 11 JORVAS FIN-02420 FINLAND
クリスチャン・フォークトエリクソン研究NomadicLab Hirsalantie 11 JORVAS FIN-02420フィンランド
Phone: EMail: christian.vogt@ericsson.com
電話番号：Eメール：christian.vogt@ericsson.com
Jari Arkko Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ヤリArkkoエリクソン研究NomadicLab JORVAS FIN-02420フィンランド
Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com
電話番号：+358 40 5079256 Eメール：jari.arkko@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。