Network Working Group T. Kivinen
Request for Comments: 4621 Safenet, Inc.
Category: Informational H. Tschofenig
Siemens
August 2006
Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).
IKEv2のモビリティとマルチホーミング（MOBIKE）プロトコルは、インターネット鍵交換プロトコルバージョン2（IKEv2の）を拡張したものです。ホストは（移動度に起因する例えば、）時間をかけて複数のIPアドレスおよび/またはIPsecのホスト変更のIPアドレスを所有しているときに、これらの拡張機能は、IKEとIPsecセキュリティアソシエーションの効率的な管理を有効にする必要があります。
This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded.
この文書は、関係するネットワークエンティティと他のプロトコルが提供するのIKEv2シグナリングと情報との関係について説明します。 MOBIKEプロトコルの設計上の意思決定、背景情報、およびワーキンググループ内で議論が記録されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Scenarios .......................................................6
3.1. Mobility Scenario ..........................................6
3.2. Multihoming Scenario .......................................7
3.3. Multihomed Laptop Scenario .................................8
4. Scope of MOBIKE .................................................8
5. Design Considerations ..........................................10
5.1. Choosing Addresses ........................................10
5.1.1. Inputs and Triggers ................................11
5.1.2. Connectivity .......................................11
5.1.3. Discovering Connectivity ...........................12
5.1.4. Decision Making ....................................12
5.1.5. Suggested Approach .................................12
5.2. NAT Traversal (NAT-T) .....................................12
5.2.1. Background and Constraints .........................12
5.2.2. Fundamental Restrictions ...........................13
5.2.3. Moving behind a NAT and Back .......................13
5.2.4. Responder behind a NAT .............................14
5.2.5. NAT Prevention .....................................15
5.2.6. Suggested Approach .................................15
5.3. Scope of SA Changes .......................................15
5.4. Zero Address Set Functionality ............................16
5.5. Return Routability Check ..................................17
5.5.1. Employing MOBIKE Results in Other Protocols ........19
5.5.2. Return Routability Failures ........................20
5.5.3. Suggested Approach .................................21
5.6. IPsec Tunnel or Transport Mode ............................22
6. Protocol Details ...............................................22
6.1. Indicating Support for MOBIKE .............................22
6.2. Path Testing and Window size ..............................23
6.3. Message Presentation ......................................24
6.4. Updating Address Set ......................................25
7. Security Considerations ........................................26
8. Acknowledgements ...............................................26
9. References .....................................................27
9.1. Normative references ......................................27
9.2. Informative References ....................................27
The purpose of IKEv2 is to mutually authenticate two hosts, to establish one or more IPsec Security Associations (SAs) between them, and subsequently to manage these SAs (for example, by rekeying or deleting). IKEv2 enables the hosts to share information that is relevant to both the usage of the cryptographic algorithms that should be employed (e.g., parameters required by cryptographic algorithms and session keys) and to the usage of local security policies, such as information about the traffic that should experience protection.
IKEv2のの目的は、相互に、二つのホストを認証するためにそれらの間で1つまたは複数のIPsecセキュリティアソシエーション（SA）を確立すること、およびその後に（再入力または削除することによって、例えば）これらのSAを管理することです。 IKEv2のは、使用すべき暗号アルゴリズムの使用方法（暗号化アルゴリズムとセッションキーで必要とされる例えば、パラメータ）の両方に及び、その結果トラフィックに関する情報として、ローカルセキュリティポリシーの使用方法に関連する情報を共有するためのホストを可能にします保護を経験する必要があります。
IKEv2 assumes that an IKE SA is created implicitly between the IP address pair that is used during the protocol execution when establishing the IKEv2 SA. This means that, in each host, only one IP address pair is stored for the IKEv2 SA as part of a single IKEv2 protocol session, and, for tunnel mode SAs, the host places this single pair in the outer IP headers. Existing IPsec documents make no provision to change this pair after an IKE SA is created (except for dynamic address update of Network Address Translation Traversal (NAT-T)).
IKEv2のは、IKE SAは、IKEv2のSAを確立する際のプロトコルの実行中に使用されるIPアドレスのペアの間で暗黙的に作成されていることを前提としています。これは、各ホストに、1つのIPアドレス対は、トンネルモードSAは、ホストの場所外側IPヘッダ内のこの単一ペアのため、単一のIKEv2プロトコルセッションの一部としてのIKEv2 SAのために格納されており、ということを意味します。 IKE SAが作成された後、既存のIPsec文書は（ネットワークの動的なアドレス更新を除い翻訳トラバーサル（NAT-T）のアドレス）は規定がこのペアを変更しないようにします。
There are scenarios where one or both of the IP addresses of this pair may change during an IPsec session. In principle, the IKE SA and all corresponding IPsec SAs could be re-established after the IP address has changed. However, this is a relatively expensive operation, and it can be problematic when such changes are frequent. Moreover, manual user interaction (for example, when using human-operated token cards (SecurID)) might be required as part of the IKEv2 authentication procedure. Therefore, an automatic mechanism is needed that updates the IP addresses associated with the IKE SA and the IPsec SAs. The MOBIKE protocol provides such a mechanism.
このペアのIPアドレスのいずれかまたは両方がIPSecセッション中に変更されることのシナリオがあります。 IPアドレスが変更された後に原則的には、IKE SAおよび対応するすべてのIPsec SAが再確立することができます。しかし、これは比較的高価な操作であり、そのような変化が頻繁である場合には問題となり得ます。また、手動のユーザ対話（例えば、人間の操作トークン・カード（SecurIDの）を使用する場合が）のIKEv2認証手順の一部として必要とされるかもしれません。したがって、自動機構は、IKE SAおよびIPSec SAの関連付けられたIPアドレスを更新することが必要です。 MOBIKEプロトコルは、このような機構を提供します。
The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As IKEv2 is built on the IPsec architecture [RFC4301], all protocols developed within the MOBIKE working group must be compatible with both IKEv2 and the architecture described in RFC 4301. This document does not discuss mobility and multi-homing support for IKEv1 [RFC2409] or the obsoleted IPsec architecture described in RFC 2401 [RFC2401].
MOBIKEプロトコルは、IKEv2の[RFC4306]の上で動作するものとします。 IKEv2のは、IPsecのアーキテクチャ[RFC4301]の上に構築されているとおり、MOBIKEワーキンググループ内で開発されたすべてのプロトコルは、IKEv2のとRFC 4301で説明アーキテクチャの両方と互換性がなければならないのIKEv1 [RFC2409]のためのモビリティとマルチホーミングサポートを議論していません。このドキュメントあるいは廃止されたIPsecアーキテクチャは、RFC 2401 [RFC2401]で説明します。
This document is structured as follows: After some important terms are introduced in Section 2, a number of relevant usage scenarios are discussed in Section 3. Section 4 describes the scope of the MOBIKE protocol. Section 5 discusses design considerations affecting the MOBIKE protocol. Section 6 investigates details regarding the MOBIKE protocol. Finally, this document concludes in Section 7 with security considerations.
MOBIKEプロトコルの範囲を記載するいくつかの重要な用語は、セクション2で導入された後、関連する使用シナリオの数は、第3のセクション4に記載されている次のようにこの文書は、構成されています。第5節では、MOBIKEプロトコルに影響を与える設計上の考慮事項について説明します。第6節は、MOBIKEプロトコルに関する詳細を調査します。最後に、この文書では、セキュリティ上の考慮事項と7節で結論します。
This section introduces the terminology that is used in this document.
このセクションでは、この文書で使用される用語を紹介します。
Peer
仲間
A peer is an IKEv2 endpoint. In addition, a peer implements the MOBIKE extensions, defined in [RFC4555].
ピアは、IKEv2のエンドポイントです。また、ピアは、[RFC4555]で定義され、MOBIKE拡張機能を実現します。
Available address
利用可能なアドレス
An address is said to be available if the following conditions are met:
アドレスは次の条件が満たされた場合に利用可能であると言われています。
* The address has been assigned to an interface.
*アドレスは、インターフェイスに割り当てられています。
* If the address is an IPv6 address, we additionally require (a) that the address is valid as defined in RFC 2461 [RFC2461], and (b) that the address is not tentative as defined in RFC 2462 [RFC2462]. In other words, we require the address assignment to be complete.
*アドレスがIPv6アドレスである場合、我々は、さらに必要（a）は、RFC 2461 [RFC2461]で定義され、RFC 2462 [RFC2462]で定義されるように（b）のアドレスが仮ではないことのように、アドレスが有効であること。言い換えれば、我々は完全であるとアドレス割り当てを必要とします。
Note that this explicitly allows an address to be optimistic as defined in [RFC4429].
これは、明示的に[RFC4429]で定義されているアドレスは楽観的にすることができますことに注意してください。
* If the address is an IPv6 address, it is a global unicast or unique site-local address, as defined in [RFC4193]. That is, it is not an IPv6 link-local address.
アドレスがIPv6アドレスの場合*、それは[RFC4193]で定義されるように、グローバルユニキャストまたはユニークなサイトローカルアドレスです。つまり、IPv6リンクローカルアドレスではありません、です。
* The address and interface is acceptable for sending and receiving traffic according to a local policy.
・アドレスとインターフェイスは、ローカルポリシーに従ってトラフィックを送受信するために許容可能です。
This definition is taken from [WIP-Ark06] and adapted for the MOBIKE context.
この定義は、[WIP-Ark06]から取り出し、MOBIKEコンテキストに適合されています。
Locally operational address
ローカル運用アドレス
An address is said to be locally operational if it is available and its use is locally known to be possible and permitted. This definition is taken from [WIP-Ark06].
アドレスは、それが利用可能であり、その使用がローカルに可能であることが知られており許可されている場合は、ローカルに動作可能と言われています。この定義は、[WIP-Ark06]から取得されます。
Operational address pair
オペレーショナル・アドレスのペア
A pair of operational addresses are said to be an operational address pair if and only if bidirectional connectivity can be shown between the two addresses. Note that sometimes it is necessary to consider connectivity on a per-flow level between two endpoints. This differentiation might be necessary to address certain Network Address Translation types or specific firewalls. This definition is taken from [WIP-Ark06] and adapted for the MOBIKE context. Although it is possible to further differentiate unidirectional and bidirectional operational address pairs, only bidirectional connectivity is relevant to this document, and unidirectional connectivity is out of scope.
オペレーショナルアドレス一対の双方向接続性は、2つのアドレス間で示すことができる場合だけ動作アドレスのペアであると言われています。時には2つのエンドポイント間のフロー単位のレベルでの接続性を考慮する必要があることに注意してください。この分化は、特定のネットワークアドレス変換の種類または特定のファイアウォールに対処する必要があるかもしれません。この定義は、[WIP-Ark06]から取り出し、MOBIKEコンテキストに適合されています。さらに単方向および双方向の運用アドレスのペアを区別することは可能ですが、唯一の双方向の接続は、このドキュメントに関連する、一方向の接続は範囲外です。
Path
道
The sequence of routers traversed by the MOBIKE and IPsec packets exchanged between the two peers. Note that this path may be affected not only by the involved source and destination IP addresses, but also by the transport protocol. Since MOBIKE and IPsec packets have a different appearance on the wire, they might be routed along a different path, for example, due to load balancing. This definition is taken from [RFC2960] and adapted to the MOBIKE context.
MOBIKEとIPsecパケットが横断するルータの配列は、2つのピア間で交換しました。このパスは、関連元および宛先IPアドレスによってだけでなく、トランスポートプロトコルによってのみならず、影響を受ける可能性があることに留意されたいです。 MOBIKEとIPsecパケットは、ワイヤ上の異なる外観を持っているので、彼らはバランスをロードすることにより、例えば、異なるパスに沿ってルーティングされる可能性があります。この定義は[RFC2960]から取り出し、MOBIKEコンテキストに適合されています。
Current path
現在のパス
The sequence of routers traversed by an IP packet that carries the default source and destination addresses is said to be the Current Path. This definition is taken from [RFC2960] and adapted to the MOBIKE context.
デフォルトの送信元アドレスと宛先アドレスを運ぶIPパケットが通過するルータの順序は、現在のパスであると言われています。この定義は[RFC2960]から取り出し、MOBIKEコンテキストに適合されています。
Preferred address
好適なアドレス
The IP address of a peer to which MOBIKE and IPsec traffic should be sent by default. A given peer has only one active preferred address at a given point in time, except for the small time period where it switches from an old to a new preferred address. This definition is taken from [WIP-Nik06] and adapted to the MOBIKE context.
MOBIKEとIPsecトラフィックはデフォルトで送信されるすべきピアのIPアドレス。与えられたピアは、それが新しい優先アドレスに古いから切り替わる小期間を除いて、特定の時点でのみアクティブ好適アドレスを有しています。この定義は、[WIP-Nik06]から取り出し、MOBIKEコンテキストに適合されています。
Peer address set
ピアアドレスセット
We denote the two peers of a MOBIKE session by peer A and peer B. A peer address set is the subset of locally operational addresses of peer A that is sent to peer B. A policy available at peer A indicates which addresses are included in the peer address set. Such a policy might be created either manually or automatically through interaction with other mechanisms that indicate new available addresses.
我々は、ピアアドレスのセットは、ピアAで利用可能なポリシーB.をピアに送信されたピアAの局所的動作アドレスのサブセットに含まれるアドレスを示しているピアAとピアBによってMOBIKEセッション二のピアを表しますピアアドレスを設定します。このような政策は、新たな利用可能なアドレスを示す他のメカニズムとの相互作用を介して、手動または自動で作成されることがあります。
Bidirectional address pair
双方向アドレスのペア
The address pair, where traffic can be sent to both directions, simply by reversing the IP addresses. Note that the path of the packets going to each direction might be different.
トラフィックは、単にIPアドレスを逆にすることにより、両方向に送信することができますアドレスペア、。各方向へ向かうパケットのパスが異なる場合がありますので注意してください。
Unidirectional address pair
単方向のアドレスのペア
The address pair, where traffic can only be sent in one direction, and reversing the IP addresses and sending reply back does not work.
アドレストラフィックが一方向のみに送信することができますペア、およびIPアドレスを逆にして動作しないバック応答を送信。
For mobility-related terminology (e.g., Make-before-break or Break-before-make), see [RFC3753].
モビリティ関連の用語について（例えば、メイク前ブレークやブレーク・ビフォア・メイク）、[RFC3753]を参照してください。
In this section, we discuss three typical usage scenarios for the MOBIKE protocol.
このセクションでは、MOBIKEプロトコルのための3つの典型的な使用シナリオを議論します。
Figure 1 shows a break-before-make mobility scenario where a mobile node (MN) changes its point of network attachment. Prior to the change, the mobile node had established an IPsec connection with a security gateway that offered, for example, access to a corporate network. The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took place over the path labeled as 'old path'. The involved packets carried the MN's "old" IP address and were forwarded by the "old" access router (OAR) to the security gateway (GW).
図1は、モバイルノード（MN）がネットワーク接続点を変更するブレーク・ビフォア・メークモビリティシナリオを示します。変更前は、モバイルノードは、例えば、企業ネットワークへのアクセスを提供するセキュリティゲートウェイとのIPSec接続を確立していました。 IPsecのSA（S）のセットアップを容易にしたのIKEv2交換は「古いパス」とラベルされたパスを介して行われました。関与パケットはMNの「古い」IPアドレスを搭載し、セキュリティゲートウェイ（GW）に「古い」アクセスルータ（OAR）によって転送されました。
When the MN changes its point of network attachment, it obtains a new IP address using stateful or stateless address configuration. The goal of MOBIKE, in this scenario, is to enable the MN and the GW to continue using the existing SAs and to avoid setting up a new IKE SA. A protocol exchange, denoted by 'MOBIKE Address Update', enables the peers to update their state as necessary.
MNは、ネットワーク接続ポイントを変更すると、それはステートフルまたはステートレスアドレス設定を使用して、新しいIPアドレスを取得します。 MOBIKEの目標は、このシナリオでは、既存のSAを継続して使用すると、新しいIKE SAの設定を避けるために、MNとGWを有効にすることです。 「MOBIKEアドレス更新」で示されるプロトコル交換は、必要に応じてそれらの状態を更新するためにピアを可能にします。
Note that in a break-before-make scenario the MN obtains the new IP address after it can no longer be reached at the old IP address. In a make-before-break scenario, the MN is, for a given period of time, reachable at both the old and the new IP address. MOBIKE should work in both of the above scenarios.
それはもはや古いIPアドレスに到達することはできないの後にブレーク・ビフォア・メークのシナリオでMNが新しいIPアドレスを取得することに注意してください。メイク・ビフォア・ブレイクのシナリオでは、MNは、一定の期間のために、古いものと新しいIPアドレスの両方で到達可能です。 MOBIKEは、上記のシナリオの両方で動作するはずです。
(Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v
. +----+ v>>>>> +--+
.move | R | -------> |GW|
. | | >>>>> | |
v +----+ ^ +--+
+--+ +---+ New path ^ ^
New IP |MN|------> |NAR|--------------^ ^
address +--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(MOBIKE Address Update)
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement
Figure 1: Mobility Scenario
図1：モビリティのシナリオ
Another MOBIKE usage scenario is depicted in Figure 2. In this scenario, the MOBIKE peers are equipped with multiple interfaces (and multiple IP addresses). Peer A has two interface cards with two IP addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 and IP_B2. Each peer selects one of its IP addresses as the preferred address, which is used for subsequent communication. Various reasons (e.g., hardware or network link failures) may require a peer to switch from one interface to another.
別のMOBIKEの使用シナリオがこのシナリオでは、図2に示されている、MOBIKEピアは、複数のインターフェース（および複数のIPアドレス）が装備されています。ピアAは、2つのIPアドレス、IP_A1とIP_A2を有する2枚のインターフェイスカードを有し、ピアBは、2つのIPアドレス、IP_B1とIP_B2を有しています。各ピアは、後続の通信に使用される好適なアドレスとしてのIPアドレスのいずれかを選択します。様々な理由（例えば、ハードウェアまたはネットワークリンク障害）別のインターフェイスから切り替えるためにピアを必要とするかもしれません。
+------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | |
+------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network
(if Peer A and Peer B change their preferred
address)
Figure 2: Multihoming Scenario
図2：マルチホーミングシナリオ
Note that MOBIKE does not aim to support load balancing between multiple IP addresses. That is, each peer uses only one of the available address pairs at a given point in time.
そのMOBIKEは、複数のIPアドレス間の負荷分散をサポートすることを目指していません。すなわち、各ピアが唯一特定の時点で利用可能なアドレス対のいずれかを使用、です。
The third scenario we consider is about a laptop that has multiple interface cards and therefore several ways to connect to the network. It may, for example, have a fixed Ethernet card, a WLAN interface, a General Packet Radio Service (GPRS) adaptor, a Bluetooth interface, or USB hardware. Not all interfaces are used for communication all the time for a number of reasons (e.g., cost, network availability, user convenience). The policies that determine which interfaces are connected to the network at any given point in time is outside the scope of the MOBIKE protocol and, as such, this document. However, as the laptop changes its point of attachment to the network, the set of IP addresses under which the laptop is reachable changes too.
私たちが考える第三のシナリオは、複数のインタフェースカード、したがって、ネットワークに接続するには、いくつかの方法を持っているノートパソコンについてです。それは、例えば、固定されたイーサネットカード、WLANインターフェース、汎用パケット無線サービス（GPRS）アダプタ、Bluetoothインタフェース、またはUSBハードウェアを有することができます。全てのインターフェイスは、多くの理由（例えば、コスト、ネットワークの可用性、ユーザの利便性）のための通信にすべての時間を使用しています。時間内の任意の所与の時点でネットワークに接続されたインターフェースを決定ポリシーは、MOBIKEプロトコルと、など、この文書の範囲外です。ノートパソコンがネットワークへの接続点を変更するようしかし、IPアドレスのセットは、ラップトップは、あまりにも到達可能な変化である下。
In all of these scenarios, even if IP addresses change due to interface switching or mobility, the IP address obtained via the configuration payloads within IKEv2 remain unaffected. The IP address obtained via the IKEv2 configuration payloads allow the configuration of the inner IP address of the IPsec tunnel. As such, applications might not detect any change at all.
これらのシナリオのすべてにおいて、IPアドレスが切り替えや移動度のインタフェースによる変更した場合でも、IKEv2の内、構成ペイロードを介して取得したIPアドレスは影響を受けません。 IKEv2構成ペイロードを介して取得したIPアドレスは、IPsecトンネルの内部IPアドレスの設定を可能にします。そのため、アプリケーションはまったく変化を検出しない場合があります。
Getting mobility and multihoming actually working requires many different components to work together, including coordinating decisions between different layers, different mobility mechanisms, and IPsec/IKEv2. Most of those aspects are beyond the scope of MOBIKE: MOBIKE focuses only on what two peers need in order to agree at the IKEv2 level (like new message formats and some aspects of their processing) required for interoperability.
実際に作業を取得モビリティとマルチホーミングは異なる層、異なるモビリティメカニズム、およびIPsec / IKEv2の間の意思決定の調整を含め、一緒に動作するように多くの異なるコンポーネントが必要です。これらの側面の大部分は、MOBIKEの範囲を超えて：MOBIKEは、2つのピアが相互運用性のために必要な（新しいメッセージの形式とその処理のいくつかの側面など）のIKEv2レベルで合意するために必要なものだけに焦点を当てています。
The MOBIKE protocol is not trying to be a full mobility protocol; there is no support for simultaneous movement or rendezvous mechanism, and there is no support for route optimization, etc. The design document focuses on tunnel mode; everything going inside the tunnel is unaffected by the changes in the tunnel header IP address, and this is the mobility feature provided by the MOBIKE. That is, applications running inside the MOBIKE-controlled IPsec tunnel might not detect the movement since their IP addresses remain constant.
MOBIKEプロトコルは、完全なモビリティプロトコルになろうとしていません。設計文書がトンネルモードに焦点を当て等、同時移動又はランデブーメカニズムのサポートはありません、そしてルート最適化のためのサポートはありません。トンネル内で起こってすべてがトンネルヘッダーのIPアドレスの変更による影響を受けない、これはMOBIKEが提供するモビリティ機能です。それは、それらのIPアドレスが一定以来MOBIKE制御IPsecトンネル内で実行中のアプリケーションが動きを検知しない場合があります、です。
The MOBIKE protocol should be able to perform the following operations (not all of which are done explicitly by the current protocol):
MOBIKEプロトコルは、（現在のプロトコルによって明示的に行われていないすべてが）次の操作を実行することができなければなりません。
o Inform the other peer about the peer address set
Oピアアドレスセットについての他のピアに知らせます
o Inform the other peer about the preferred address
O好適アドレスについての他のピアに通知
o Test connectivity along a path and thereby detect an outage situation
Oテスト経路に沿って接続し、それによっては停止状態を検出します
o Change the preferred address
O優先アドレスを変更
o Change the peer address set
Oピアアドレス設定を変更します
o Ability to deal with Network Address Translation devices
ネットワークアドレス変換デバイスに対処する能力をO
Figure 3 shows an example protocol interaction between a pair of MOBIKE peers. MOBIKE interacts with the packet processing module of the IPsec implementation using an internal API (such as those based on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create entries in the Security Association (SAD) and Security Policy Databases (SPD). The packet processing module of the IPsec implementation may also interact with IKEv2 and MOBIKE module using this API. The content of the Security Policy and Security Association Databases determines what traffic is protected with IPsec in which fashion. MOBIKE, on the other hand, receives information from a number of sources that may run both in kernel-mode and in user-mode. These sources form the basis on which MOBIKE makes decisions regarding the set of available addresses, the peer address set, and the preferred address. Policies may also affect the selection process.
図3は、MOBIKEピアの対の間の例示的なプロトコルの相互作用を示します。 MOBIKEは、（PF_KEY [RFC2367]に基づくものなど）は、内部APIを使用して、IPsec実装のパケット処理モジュールと相互作用します。このAPIを使用して、MOBIKEモジュールは、セキュリティアソシエーション（SAD）とセキュリティポリシーデータベース（SPD）にエントリを作成することができます。 IPsec実装のパケット処理モジュールは、このAPIを使用してのIKEv2とMOBIKEモジュールと相互作用することができます。セキュリティポリシーとセキュリティアソシエーションデータベースの内容は、トラフィックがファッションのIPsecで保護されているかを決定します。 MOBIKE、一方、カーネルモードとユーザモードの両方で実行することができる多数のソースからの情報を受信します。これらのソースはMOBIKEが利用可能なアドレスのセットに関する決定、ピアアドレスセット、および優先アドレスを行った上で基礎を形成します。ポリシーはまた、選択プロセスに影響を与える可能性があります。
The peer address set and the preferred address needs to be made available to the other peer. In order to address certain failure cases, MOBIKE should perform connectivity tests between the peers (potentially over a number of different paths). Although a number of address pairs may be available for such tests, the most important is the pair (source address, destination address) of the current path. This is because this pair is selected for sending and receiving MOBIKE signaling and IPsec traffic. If a problem along this current path is detected (e.g., due to a router failure), it is necessary to switch to a new current path. In order to be able to do so quickly, it may be helpful to perform connectivity tests of other paths periodically. Such a technique would also help identify previously disconnected paths that become operational again.
ピアアドレスのセットと好適アドレスが他のピアに利用可能にする必要があります。特定の障害の場合に対処するために、MOBIKEは、（潜在的に異なるパス数にわたって）ピア間の接続性テストを行うべきです。アドレスペアの数は、テストのために利用できるかもしれないが、最も重要なのは、現在のパスのペア（送信元アドレス、宛先アドレス）です。このペアは、MOBIKEシグナリングおよびIPsecトラフィックを送受信するために選択されているためです。この電流経路に沿って問題を（ルータの障害に、例えばによる）検出された場合、新たな電流経路に切り替える必要があります。こんなに早く行うことができるようにするためには、定期的に他のパスの接続性テストを実行するために役立つかもしれません。このような技術はまた、再び動作可能になる以前に切断されたパスを識別するのに役立つでしょう。
+---------------------+ +----------------+
| User-space | | |
| Protocols and | | MOBIKE and |
| Functions Relevant |<---------->| IKEv2 Module |
| MOBIKE (e.g., DHCP, | | |
| policies) | +----------------+
+---------------------+ ^
^ |
| | User space
++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++
| | Kernel space
| v
| +----------------+
v | |
+---------------------+ | IPsec engine |
| Kernel-space |<---------->| (and databases)|
| Protocols | | |
| Relevant for | +----------------+
| MOBIKE (e.g., ND, | ^
| DNA, L2) |<---------------+ |
+---------------------+ v v
|| +----------------+
\/ | |
Inter- =====================>| IP forwarding, |
faces <=====================|input and output|
| |
+----------------+
===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations
Figure 3: Framework
図3：フレームワーク
Please note that Figure 3 illustrates an example of how a MOBIKE implementation could work. It serves illustrative purposes only.
図3は、MOBIKE実装が仕事ができる方法の例を示していることに注意してください。これは、例示のみの目的があります。
This section discusses aspects affecting the design of the MOBIKE protocol.
このセクションでは、MOBIKEプロトコルの設計に影響を与える側面について説明します。
One of the core aspects of the MOBIKE protocol is the selection of the address for the IPsec packets we send. Choosing addresses for the IKEv2 request is a somewhat separate problem. In many cases, they will be the same (and in some design choice they will always be the same and could be forced to be the same by design).
MOBIKEプロトコルのコア側面の一つは、我々が送信IPSecパケットのアドレスの選択です。 IKEv2の要求のためのアドレスを選択すると、やや別の問題です。多くの場合、彼らは同じになります（といくつかの設計上の選択では、それらは常に同じになり、設計で同じになるように強制することができます）。
How address changes are triggered is largely beyond the scope of MOBIKE. The triggers can include changes in the set of addresses, various link-layer indications, failing dead peer detection, and changes in preferences and policies. Furthermore, there may be less reliable sources of information (such as lack of IPsec packets and incoming ICMP packets) that do not trigger any changes directly, but rather cause Dead Peer Detection (DPD) to be scheduled earlier and, if it fails, it might cause a change of the preferred address.
アドレスの変更がトリガされているどのように大幅にMOBIKEの範囲を超えています。トリガーは、アドレスのセットの変化、様々なリンク層指摘、死んだピアの検出に失敗し、好みや政策の変更を含めることができます。さらに、それは、直接変更をトリガするのではなく、それが失敗した場合、先にスケジュールするためのデッドピア検出（DPD）が発生していない（たとえば、IPsecパケットと、着信ICMPパケットの欠落など）の情報の信頼性の低い情報源があるかもしれません優先アドレスの変更が発生する可能性があります。
These triggers are largely the same as for other mobility protocols such as Mobile IP, and they are beyond the scope of MOBIKE.
これらのトリガーは、主なモバイルIPなどの他のモビリティプロトコルの場合と同じであり、それらはMOBIKEの範囲を超えています。
There can be two kinds of connectivity "failures": local failures and path failures. Local failures are problems locally at a MOBIKE peer (e.g., an interface error). Path failures are a property of an address pair and failures of nodes and links along this path. MOBIKE does not support unidirectional address pairs. Supporting them would require abandoning the principle of sending an IKEv2 reply to the address from which the request came. MOBIKE decided to deal only with bidirectional address pairs. It does consider unidirectional address pairs as broken and does not use them, but the connection between peers will not break even if unidirectional address pairs are present, provided there is at least one bidirectional address pair MOBIKE can use.
地元の障害やパス障害：接続の「失敗」の2種類が存在する場合があります。ローカル障害はMOBIKEピア（例えば、インタフェースエラー）で局所的な問題です。パス障害は、この経路に沿ったノードおよびリンクのアドレス対と障害の性質です。 MOBIKEは、一方向のアドレスのペアをサポートしていません。それらをサポートする要求が来たからアドレスへのIKEv2応答を送信する原則を放棄が必要となります。 MOBIKEは、双方向のアドレスのペアでのみ扱うことにしました。壊れたとそれらを使用しませんが、ピア間の接続は、単方向のアドレスのペアが存在する場合であっても中断されません、使用することができる少なくとも1つの双方向のアドレスペアMOBIKEが提供されるように、それは一方向のアドレスのペアを考慮しません。
Note that MOBIKE is not concerned about the actual path used; it cannot even detect if some path is unidirectionally operational if the same address pair has some other unidirectional path back. Ingress filters might still cause such path pairs to be unusable, and in that case MOBIKE will detect that there is no operational address pair.
MOBIKEを使用する実際のパスを心配はないことに留意されたいです。同じアドレスのペアが戻っていくつかの他の単方向のパスを持っている場合、いくつかのパスが一方向に動作している場合はそれも検出することはできません。イングレスフィルタは、まだ、このようなパスのペアが使用不能にさせるかもしれませんが、その場合にMOBIKEには、動作アドレスペアが存在しないことを検出します。
In a sense having both an IPv4 and an IPv6 address is basically a case of partial connectivity (putting both an IPv4 and an IPv6 address in the same IP header does not work). The main difference is that it is known beforehand; there is no need to discover that an IPv4/IPv6 combination does not work.
IPv4およびIPv6アドレスの両方を有する意味で（同じIPヘッダーのIPv4およびIPv6アドレスの両方が機能しない置く）は、基本的に、部分接続の場合です。主な違いは、それが予め分かっていることです。 IPv4 / IPv6統合が動作しないことを発見する必要はありません。
To detect connectivity, the MOBIKE protocol needs to have a mechanism to test connectivity. If a MOBIKE peer receives a reply, it can be sure about the existence of a working (bidirectional) address pair. If a MOBIKE peer does not see a reply after multiple retransmissions, it may assume that the tested address pair is broken.
接続を検出するために、MOBIKEプロトコルは、接続をテストするためのメカニズムを持っている必要があります。 MOBIKEピアが応答を受信した場合、それは作業（双方向）アドレスペアの存在について確認することができます。 MOBIKEピアは、複数の再送信後、返信を見ていない場合は、テストしたアドレスのペアが壊れていることを仮定してもよいです。
The connectivity tests require congestion problems to be taken into account because the connection failure might be caused by congestion. The MOBIKE protocol should not make the congestion problem worse by sending many DPD packets.
接続テストは、接続障害が輻輳が原因で発生する可能性があるため、輻輳問題を考慮しなければ必要があります。 MOBIKEプロトコルは、多くのDPDパケットを送信することにより、輻輳問題を悪化させるべきではありません。
One of the main questions in designing the MOBIKE protocol was who makes the decisions how to fix a situation when failure is detected, e.g., symmetry vs. asymmetry in decision making. Symmetric decision making (i.e., both peers can make decisions) may cause the different peers to make different decisions, thus causing asymmetric upstream/ downstream traffic. In the mobility case, it is desirable that the mobile peer can move both upstream and downstream traffic to some particular interface, and this requires asymmetric decision making (i.e. only one peer makes decisions).
MOBIKEプロトコルを設計する上での主要な問題の一つは、意思決定における非対称対例えば、対称性、障害が検出されたときの状況を修正する方法を決定をする人でした。対称的な意思決定（すなわち、両方のピアが決定を下すことができる）、したがって非対称アップストリーム/ダウンストリームトラフィックを引き起こし、異なる決定を行うために異なるピアを引き起こす可能性があります。モビリティの場合には（すなわち、唯一のピアが決定を行う）モバイルピアがいくつかの特定のインタフェースの両方上流および下流トラフィックを移動させることができ、これは非対称の意思決定を必要とすることが望ましいです。
Working with stateful packet filters and NATs is easier if the same address pair is used in both upstream and downstream directions. Also, in common cases, only the peer behind NAT can actually perform actions to recover from the connectivity problems, as the other peer might not be able to initiate any connections to the peer behind NAT.
同じアドレスのペアが上流と下流の両方向に使用されている場合は、ステートフルパケットフィルタとNATを使った作業が容易です。他のピアがNATの背後にあるピアへの接続を開始できないことがありますよう。また、一般的なケースでは、NATの背後にある唯一のピアは、実際に、接続の問題から回復するためのアクションを実行することができます。
The working group decided to select a method whereby the initiator will decide which addresses are used. As a consequence, the outcome is always the same for both parties. It also works best with NATs, as the initiator is most likely the node that is located behind a NAT.
ワーキンググループは、開始剤が使用されているアドレスを決定することにより、この方法を選択することにしました。その結果、結果は常に双方にとって同じです。イニシエータが最も可能性が高いNATの背後に配置されているノードであるとして、それはまた、NATのに最適です。
Another core aspect of MOBIKE is the treatment of different NATs and Network Address Port Translations (NAPTs). In IKEv2 the tunnel header IP addresses are not sent inside the IKEv2 payloads, and thus there is no need to do unilateral self-address fixing (UNSAF
MOBIKEの別のコアの側面は、異なるNATのネットワークアドレスポート変換（NAPTs）の治療です。 IKEv2トンネルヘッダIPアドレスはUNSAF（のIKEv2ペイロード内部送られ、従って片側自己アドレス固定を行う必要はありませんされていません
[RFC3424]). The tunnel header IP addresses are taken from the outer IP header of the IKE packets; thus, they are already processed by the NAT.
[RFC3424]）。トンネルヘッダのIPアドレスは、IKEパケットの外側IPヘッダから取られます。このように、彼らはすでにNATによって処理されています。
The NAT detection payloads are used to determine whether the addresses in the IP header were modified by a NAT along the path. Detecting a NAT typically requires UDP encapsulation of IPsec ESP packets to be enabled, if desired. MOBIKE is not to change how IKEv2 NAT-T works in particular, any kind of UNSAF or explicit interaction with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [WIP-Sti06]) is beyond the scope of the MOBIKE protocol. The MOBIKE protocol will need to define how MOBIKE and NAT-T are used together.
NAT検出ペイロードは、IPヘッダのアドレスは、パスに沿ってNATによって変更されたかどうかを決定するために使用されます。 NATを検出することは一般的に必要に応じてIPsecのESPパケットのUDPカプセル化が、有効にする必要があります。 MOBIKEは、IKEv2のNAT-Tは、具体的にどのように動作するか変更しないで、NATを有するUNSAFまたは明示的な相互作用の任意の種類（例えば、MIDCOM [RFC3303]またはNSIS NATFW NSLP [WIP-Sti06]）はMOBIKEプロトコルの範囲を超えています。 MOBIKEプロトコルは、MOBIKEとNAT-Tを一緒に使用する方法を定義する必要があります。
The NAT-T support should also be optional. If the IKEv2 implementation does not implement NAT-T, as it is not required in some particular environment, implementing MOBIKE should not require adding support for NAT-T either.
NAT-Tのサポートもオプションでなければなりません。 IKEv2の実装はNAT-Tを実装していない場合、それはいくつかの特定の環境で必要とされていないとして、MOBIKEを実装することのいずれかNAT-Tのサポートを追加する必要はありません。
The property of being behind NAT is actually a property of the address pair and thereby of the path taken by a packet. Thus, one peer can have multiple IP addresses, and some of those might be behind NAT and some might not.
NATの背後にあるという特性は、実際には、それによってパケットによって取られる経路のアドレスペアの特性です。このように、一方のピアは、複数のIPアドレスを持つことができ、そのうちのいくつかは、NATの背後にあるかもしれないといくつかではないかもしれません。
There are some cases that cannot be carried out within MOBIKE. One of those cases is when the party "outside" a symmetric NAT changes its address to something not known by the other peer (and the old address has stopped working). It cannot send a packet containing the new addresses to the peer because the NAT does not contain the necessary state. Furthermore, since the party behind the NAT does not know the new IP address, it cannot cause the NAT state to be created.
MOBIKE内で行うことができない場合があります。当事者が「外」対称NATは、他のピア（と動作を停止しました旧アドレス）によって知られていない何かにそのアドレスを変更したときに、それらの例の一つです。 NATが必要な状態が含まれていないので、それはピアに新しいアドレスを含むパケットを送信することはできません。 NATの背後にある当事者が新しいIPアドレスを知らないので、それはNAT状態を作成させることができません。
This case could be solved using some rendezvous mechanism outside IKEv2, but that is beyond the scope of MOBIKE.
この場合には、IKEv2の外いくつかのランデブーメカニズムを使用して解決することができ、それはMOBIKEの範囲を超えています。
The MOBIKE protocol should provide a mechanism whereby a peer that is initially not behind a NAT can move behind NAT when a new preferred address is selected. The same effect might be accomplished with the change of the address pair if more than one path is available (e.g., in the case of a multi-homed host). An impact for the MOBIKE protocol is only caused when the currently selected address pair causes MOBIKE packets to traverse a NAT.
MOBIKEプロトコルは、新しい優先アドレスが選択されたときにNATの背後最初ないピアがNATの背後に移動することができる機構を提供しなければなりません。複数のパスが（マルチホームホストの場合、例えば、）利用可能な場合、同じ効果は、アドレス対の変化を用いて達成されるかもしれません。現在選択されたアドレス対がMOBIKEパケットがNATを通過させるときにMOBIKEプロトコルの影響のみ引き起こされます。
Similarly, the MOBIKE protocol provides a mechanism to detect when a NATed path is changed to a non-NATed path with the change of the address pair.
同様に、MOBIKEプロトコルはNAT処理経路がアドレス対の変化を有する非NAT変換パスに変更されたときを検出するための機構を提供します。
As we only use one address pair at time, effectively the MOBIKE peer is either behind NAT or not behind NAT, but each address change can change this situation. Because of this, and because the initiator always chooses the addresses, it is enough to send keepalive packets only to that one address pair.
我々は一度に一つのアドレスペアを使用すると、効果的にMOBIKEピアはNATの後ろかNATの背後のどちらかであるが、各アドレスの変更は、この状況を変えることができます。このため、イニシエータは常にアドレスを選択しますので、それだけで1つのアドレスペアにキープアライブパケットを送信するのに十分です。
Enabling NAT-T involves a few different things. One is to enable the UDP encapsulation of ESP packets. Another is to change the IKE SA ports from port 500 to port 4500. We do not want to do unnecessary UDP encapsulation unless there is really a NAT between peers, i.e., UDP encapsulation should only be enabled when we actually detect NAT. On the other hand, as all implementations supporting NAT-T must be able to respond to port 4500 all the time, it is simpler from the protocol point of view to change the port numbers from 500 to 4500 immediately upon detecting that the other end supports NAT-T. This way it is not necessary to change ports after we later detected NAT, which would have caused complications to the protocol.
NAT-Tを有効にすると、いくつかの異なるものが含まれます。一つは、ESPパケットのUDPカプセル化を可能にするためです。もう一つは、私たちが実際にNATを検出したとき、すなわち、UDPカプセル化が唯一有効にする必要があるピア間のNATは、実際に存在しない限り、私たちは、不要なUDPカプセル化を行うにはしたくないポート4500にポート500からIKE SAのポートを変更することです。一方、NAT-Tをサポートしているすべての実装として、直ちに他端サポートしていることを検出すると、500から4500までのポート番号を変更するビューのプロトコルの観点から簡単であるポート4500へのすべての時間を応答することができなければなりませんNAT-T。私たちは、後でプロトコルに合併症を引き起こしているだろうNATを、検出された後、この方法は、ポートを変更する必要はありません。
If we changed the port only after we detected NAT, then the responder would not be able to use the IKE and IPsec SAs immediately after their address is changed to be behind NAT. Instead, it would need to wait for the next packet from the initiator to see what IP and port numbers are used after the initiator changed its port from 500 to 4500. The responder would also not be able to send anything to the initiator before the initiator sent something to the responder. If we do the port number changing immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we get the rid of this problem.
我々はNATを検出した後にのみ、ポートを変更した場合は、そのアドレスがNATの背後に変更された直後に、その後、レスポンダはIKEとIPsec SAを使用することはできません。その代わりに、イニシエータは500から4500までのポートを変更した後、レスポンダはまた、イニシエータ前にイニシエータに何かを送ることができないだろうIPとポート番号が使用されているかを確認するために、イニシエータから次のパケットを待つ必要があるだろうレスポンダに何かを送りました。私たちはIKE_SA_INIT後とIKE_AUTHフェーズの直前に変更したポート番号をすれば、我々はこの問題を取り除きます。
MOBIKE can work in cases where the responder is behind a static NAT, but the initiator would need to know all the possible addresses to which the responder can move. That is, the responder cannot move to an address which is not known by the initiator, in case initiator also moves behind NAT.
MOBIKEは、応答者が静的NATの背後にあるが、イニシエータがレスポンダが移動することができているすべての可能なアドレスを知っておく必要があります例で作業することができます。すなわち、レスポンダはイニシエータはまた、NATの背後に移動する場合には、イニシエータによって知られていないアドレスに移動することができません。
If the responder is behind a NAPT, then it might need to communicate with the NAT to create a mapping so the initiator can connect to it. Those external firewall pinhole opening mechanisms are beyond the scope of MOBIKE.
レスポンダがNAPTの背後にある場合、それは、イニシエータがそれに接続できるようにマッピングを作成するために、NATと通信する必要がある場合があります。これらの外部ファイアウォールピンホール開口部のメカニズムは、MOBIKEの範囲を超えています。
In case the responder is behind NAPT, then finding the port numbers used by the responder is outside the scope of MOBIKE.
レスポンダは、NAPTの背後にある場合には、次いで、応答者によって使用されるポート番号を見つけることMOBIKEの範囲外です。
One new feature created by MOBIKE is NAT prevention. If we detect NAT between the peers, we do not allow that address pair to be used. This can be used to protect IP addresses in cases where the configuration knows that there is no NAT between the nodes (for example IPv6, or fixed site-to-site VPN). This avoids any possibility of on-path attackers modifying addresses in headers. This feature means that we authenticate the IP address and detect if they were changed. As this is done on purpose to break the connectivity if NAT is detected, and decided by the configuration, there is no need to do UNSAF processing.
MOBIKEによって作成された新機能の1つは、NAT予防です。我々はピア間でNATを検出した場合、我々はそのアドレスのペアを使用することはできません。この構成は、ノード（例えばIPv6の、または固定サイト間VPN）との間にNATが存在しないことを知っている場合にはIPアドレスを保護するために使用することができます。これは、ヘッダのアドレスの変更のパス攻撃者の任意の可能性を回避します。この機能は、我々はIPアドレスを認証し、それらが変更されたかどうかを検出することを意味します。これは、NATが検出された場合、接続を切断する目的で行われ、コンフィギュレーションによって決定されると、UNSAF処理を行う必要はありません。
The working group decided that MOBIKE uses NAT-T mechanisms from the IKEv2 protocol as much as possible, but decided to change the dynamic address update (see [RFC4306], Section 2.23, second to last paragraph) for IKEv2 packets to "MUST NOT" (it would break path testing using IKEv2 packets; see Section 6.2). The working group also decided only to send keepalives to the current address pair.
IKEv2のパケットは、「NOT MUST」にするためのワーキンググループは、（第2の最後の段落に、セクション2.23、[RFC4306]を参照）MOBIKEは、IKEv2のプロトコルからできるだけNAT-Tメカニズムを使用することを決めたが、動的アドレス更新を変更することを決めました（これは、IKEv2のパケットを使用してテストパスを破る;セクション6.2を参照してください）。ワーキンググループはまた、唯一の現在のアドレスペアにキープアライブを送信することを決定しました。
Most sections of this document discuss design considerations for updating and maintaining addresses in the database entries that relate to an IKE SA. However, changing the preferred address also affects the entries of the IPsec SA database. The outer tunnel header addresses (source and destination IP addresses) need to be modified according to the current path to allow the IPsec protected data traffic to travel along the same path as the MOBIKE packets. If the MOBIKE messages and the IPsec protected data traffic travel along a different path, then NAT handling is severely complicated.
このドキュメントのほとんどのセクションでは、IKE SAに関連するデータベースエントリのアドレスを更新し、維持するための設計上の考慮事項について説明します。しかし、好ましいアドレスを変更すると、IPsecのSAデータベースのエントリに影響を与えます。外側のトンネルヘッダアドレス（送信元および宛先IPアドレス）にIPsec保護されたデータトラフィックは、MOBIKEパケットと同じ経路に沿って移動できるようにするために電流経路に応じて変更する必要があります。 MOBIKEメッセージとは別の経路に沿ってのIPsec保護されたデータトラフィックの旅行場合、NAT取り扱いが厳しく複雑です。
The basic question is then how the IPsec SAs are changed to use the new address pair (the same address pair as the MOBIKE signaling traffic). One option is that when the IKE SA address is changed, all IPsec SAs associated with it are automatically moved along with it to a new address pair. Another option is to have a separate exchange to move the IPsec SAs separately.
基本的な質問は、IPsec SAを新しいアドレスペア（MOBIKEシグナリングトラフィックと同じアドレスのペア）を使用するように変更されているどのようにしてあります。 1つのオプションは、IKE SAアドレスが変更されたときに、それに関連するすべてのIPsec SAが自動的に新しいアドレスペアにそれに沿って移動していることです。別のオプションは、個別のIPsec SAを移動するために別々の交流を持つことです。
If IPsec SAs should be updated separately, then a more efficient format than the Notify payload is needed to preserve bandwidth. A Notify payload can only store one Security Parameter Index (SPI) per payload. A separate payload could have a list of IPsec SA SPIs and the new preferred address. If there is a large number of IPsec SAs, those payloads can be quite large unless list of ranges of SPI values are supported. If we automatically move all IPsec SAs when the IKE
IPsecのSAが個別に更新する必要がある場合には、通知ペイロードよりも効率的なフォーマットは、帯域幅を維持するために必要とされます。通知ペイロードは、ペイロードのみごとにセキュリティパラメータインデックス（SPI）を保存することができます。別のペイロードは、IPsec SAのSPIおよび新たな優先アドレスのリストを持つことができます。 IPsecのSAの数が多い場合には、SPI値の範囲のリストがサポートされていない限り、それらのペイロードが非常に大きくなることができます。私たちは、自動的にすべてのIPsec SAのIKEを移動した場合
SA moves, then we only need to keep track of which IKE SA was used to create the IPsec SA, and fetch the IP addresses from the IKE SA, i.e., there is no need to store IP addresses per IPsec SA. Note that IKEv2 [RFC4306] already requires the implementations to keep track of which IPsec SAs are created using which IKE SA.
SAの移動は、その後、我々は唯一のIKE SAは、IPsecのSAを作成するために使用されたのを追跡して、IKE SAからIPアドレスを取得する必要がある、すなわち、IPsecのSAごとにIPアドレスを保存する必要はありません。 IKEv2の[RFC4306]はすでにIPsecのSAがどのIKE SAを使用して作成されているのを追跡するために実装する必要があることに注意してください。
If we do allow the address set of each IPsec SA to be updated separately, then we can support scenarios where the machine has fast and/or cheap connections and slow and/or expensive connections and wants to allow moving some of the SAs to the slower and/or more expensive connection, and prevent the move, for example, of the news video stream from the WLAN to the GPRS link.
私たちはそれぞれのIPsec SAのアドレスセットを個別に更新できるようにした場合は、その後、我々はマシンが速く、および/または安価な接続と低速および/または高価な接続を持っていると遅くにSAの一部を移動できるようにしたいシナリオをサポートすることができますおよび/またはより高価な接続、および移動を防ぐため、例えば、GPRSリンクへのWLANからのニュース映像ストリームの。
On the other hand, even if we tie the IKE SA update to the IPsec SA update, we can create separate IKE SAs for this scenario. For example, we create one IKE SA that has both links as endpoints, and it is used for important traffic; then we create another IKE SA which has only the fast and/or cheap connection, which is used for that kind of bulk traffic.
一方、我々はIPsec SAの更新にIKE SAの更新を結ぶ場合でも、私たちはこのシナリオのために別のIKE SAを作成することができます。例えば、我々は、エンドポイントとして、両方のリンクがあり、それが重要なトラフィックに使用される1 IKE SAを作成します。その後、我々は、バルクトラフィックのようなもののためにのみ使用され、高速かつ/または安価な接続を持っている他のIKE SAを作成します。
The working group decided to move all IPsec SAs implicitly when the IKE SA address pair changes. If more granular handling of the IPsec SA is required, then multiple IKE SAs can be created one for each set of IPsec SAs needed.
ワーキンググループは、暗黙的にするとき、IKE SAのアドレスのペアの変更をすべてのIPsec SAを移動することを決めました。 IPsecのSAのより細かい取り扱いが必要な場合は、複数のIKE SAが必要なのIPsec SAのセットごとに1を作成することができます。
One of the features that is potentially useful is for the peer to announce that it will now disconnect for some time, i.e., it will not be reachable at all. For instance, a laptop might go to suspend mode. In this case, it could send address notification with zero new addresses, which would mean that it will not have any valid addresses anymore. The responder would then acknowledge that notification and could then temporarily disable all SAs and therefore stop sending traffic. If any of the SAs get any packets, they are simply dropped. This could also include some kind of ACK spoofing to keep the TCP/IP sessions alive (or simply setting the TCP/IP keepalives and timeouts large enough not to cause problems), or it could simply be left to the applications, e.g., allow TCP/IP sessions to notice if the link is broken.
ピアは、すなわち、それがすべてで到達できないだろう、それは今いくつかの時間のために切断されることを発表するために有用である可能性がある特徴の一つです。例えば、ノートパソコンはサスペンドモードに行くかもしれません。この場合、それはもはや任意の有効なアドレスを持っていないことを意味するゼロ新しいアドレスとアドレス通知を送信することができます。応答者は、その通知を認めるだろうし、その後一時的にすべてのSAを無効にするため、トラフィックの送信を停止することができます。 SAのいずれかの任意のパケットを取得する場合、彼らは単に廃棄されます。例えば、許可TCP、これはまた、生きている（または単にTCP / IPキープアライブを設定し、問題を起こさない程度に大きなタイムアウト）TCP / IPセッションを維持するためにACKスプーフィングのいくつかの種類を含むことができ、またはそれは単にアプリケーションに任せることができましたリンクが壊れている場合/ IPセッションは通知に。
The local policy could then indicate how long the peer should allow remote peers to remain disconnected.
ローカルポリシーは、ピアは、リモートピアが切断されたままにできるようにする必要がありますどのくらいの時間を示すことができます。
From a technical point of view, this would provide following two features: o There is no need to transmit IPsec data traffic. IPsec-protected data can be dropped, which saves bandwidth. This does not provide a functional benefit, i.e., nothing breaks if this feature is not provided.
技術的な観点から、これは、次の2つの機能を提供する：IPsecのデータトラフィックを送信する必要はありませんoを。 IPsecで保護されたデータは、帯域幅を節約する、ドロップすることができます。これは、この機能が提供されない場合、すなわち、何も壊れない、機能的な利点を提供していません。
o MOBIKE signaling messages are also ignored. The IKE SA must not be deleted, and the suspend functionality (realized with the zero address set) may require the IKE SA to be tagged with a lifetime value since the IKE SA should not be kept alive for an undefined period of time. Note that IKEv2 does not require that the IKE SA has a lifetime associated with it. In order to prevent the IKE SA from being deleted, the dead-peer detection mechanism needs to be suspended as well.
シグナリングメッセージを入出力MOBIKEも無視されます。 IKE SAを削除してはならない、とIKE SAが時間の未定義の期間生き維持されるべきではないので、IKE SAを必要とするかもしれない（ゼロアドレスセットで実現）サスペンド機能が寿命値でタグ付けされます。 IKEv2のは、IKE SAは、それに関連付けられた寿命を持っていることを必要としないことに注意してください。削除されるのIKE SAを防止するために、デッド・ピア検出機構も中断する必要があります。
Due to its complexity and no clear requirement for it, it was decided that MOBIKE does not support this feature.
その複雑さとそれのための明確な要件のために、それはMOBIKE、この機能をサポートしていないことを決定しました。
Changing the preferred address and subsequently using it for communication is associated with an authorization decision: Is a peer allowed to use this address? Does this peer own this address? Two mechanisms have been proposed in the past to allow a peer to determine the answer to these questions:
通信のためにそれを優先アドレスを変更し、その後使用が認可判断に関連付けられている：ピアは、このアドレスを使用することを許可されていますか？このピアは、このアドレスを所有していますか？ 2つのメカニズムがこれらの質問への答えを決定するためにピアを可能にするために、過去に提案されています。
o The addresses a peer is using are part of a certificate. [RFC3554] introduced this approach. If the other peer is, for example, a security gateway with a limited set of fixed IP addresses, then the security gateway may have a certificate with all the IP addresses appearing in the certificate.
ピアが使用しているアドレスO証明書の一部です。 [RFC3554]は、このアプローチを導入しました。他のピアは、例えば、固定IPアドレスの限定されたセットとセキュリティゲートウェイである場合、セキュリティゲートウェイは、証明書内に現れるすべてのIPアドレスを持つ証明書を有していてもよいです。
o A return routability check is performed by the remote peer before the address is updated in that peer's Security Association Database. This is done in order to provide a certain degree of confidence to the remote peer that the local peer is reachable at the indicated address.
アドレスはそのピアのセキュリティアソシエーションデータベースで更新される前に、Oリターン・ルータビリティ・チェックは、リモートピアによって行われます。これは、ローカルピアが示すアドレスに到達可能なリモートピアへの信頼のある程度を提供するために行われます。
Without taking an authorization decision, a malicious peer can redirect traffic towards a third party or a black hole.
承認決定を取ることなく、悪意あるピアは、第三者またはブラックホールの方にトラフィックをリダイレクトすることができます。
A MOBIKE peer should not use an IP address provided by another MOBIKE peer as a current address without computing the authorization decision. If the addresses are part of the certificate, then it is not necessary to execute the return routability check. The return routability check is a form of authorization check, although it provides weaker guarantees than the inclusion of the IP address as a part of a certificate. If multiple addresses are communicated to the remote peer, then some of these addresses may be already verified.
MOBIKEピアは、認可決定を計算することなく、現在のアドレスとして別のMOBIKEピアが提供するIPアドレスを使用しないでください。アドレスは、証明書の一部である場合、リターン・ルータビリティ・チェックを実行する必要はありません。それは証明書の一部としてIPアドレスを含めることよりも弱いの保証を提供するが、リターン・ルータビリティチェックは、認証チェックの形です。複数のアドレスがリモートピアに通信される場合、これらのアドレスの一部が既に確認されてもよいです。
Finally, it would be possible not to execute return routability checks at all. In case of indirect change notifications (i.e., something we notice from the network, not from the peer directly), we only move to the new preferred address after successful dead-peer detection (i.e., a response to a DPD test) on the new address, which is already a return routability check. With a direct notification (i.e., notification from the other end directly) the authenticated peer may have provided an authenticated IP address (i.e., inside IKE encrypted and authenticated payload; see Section 5.2.5). Thus, it is would be possible simply to trust the MOBIKE peer to provide a proper IP address. In this case, a protection against an internal attacker (i.e., the authenticated peer forwarding its traffic to the new address) would not provided. On the other hand, we know the identity of the peer in that case. There might be problems when extensions are added to IKEv2 that do not require authentication of end points (e.g., opportunistic security using anonymous Diffie-Hellman).
最後に、すべてのリターン・ルータビリティ・チェックを実行しないことも可能です。間接的な変更通知の場合（つまり、私たちはネットワークから気づく何かは、直接ではなくピアから）、私たちは、新しいオンに成功デッドピア検出（すなわち、DPDテストへの応答）の後に、新たな優先アドレスに移動しますすでにリターン・ルータビリティ・チェックでアドレス、。 （; 5.2.5項を参照して、即ち、IKE暗号化および認証されたペイロード内）直接通知して（すなわち、他の端からの通知は、直接的に）認証されたピアが認証されたIPアドレスを提供していてもよいです。したがって、それは単に適切なIPアドレスを提供するために、MOBIKEピアを信頼することが可能であるです。この場合、内部攻撃に対する保護（すなわち、新アドレスへのトラフィックの転送を認証ピア）が設けられていないであろう。一方、我々は、その場合には、ピアのアイデンティティを知っています。エンドポイントの認証を必要としない拡張機能はIKEv2のに追加された問題があるかもしれません（例えば、匿名のディフィー・ヘルマンを使用して日和見セキュリティ）。
There is also a policy issue of when to schedule a return routability check. Before moving traffic? After moving traffic?
リターンルータビリティチェックをスケジュールする際の政策課題もあります。トラフィックを移動する前に？トラフィックを移動した後？
The basic format of the return routability check could be similar to dead-peer detection, but potential attacks are possible if a return routability check does not include some kind of a nonce. In these attacks, the valid end point could send an address update notification for a third party, trying to get all the traffic to be sent there, causing a denial-of-service attack. If the return routability check does not contain any nonce or other random information not known to the other peer, then the other peer could reply to the return routability checks even when it cannot see the request. This might cause a peer to move the traffic to a location where the original recipient cannot be reached.
リターン・ルータビリティチェックの基本的な形式は、デッドピア検出に似たかもしれないが、リターン・ルータビリティ・チェックはナンスのいくつかの種類が含まれていない場合の潜在的な攻撃が可能です。これらの攻撃では、有効なエンドポイントは、サービス拒否攻撃を引き起こし、そこに送信されるすべてのトラフィックを取得しようと、第三者のためのアドレス更新通知を送信することができます。リターン・ルータビリティ・チェックは、任意のナンスや他のピアに知られていない他のランダムな情報が含まれていない場合、それは要求を見ることができない場合でも、その後、他のピアは、リターン・ルータビリティチェックに返信ができます。これは、ピアが元の受信者に到達できない場所へのトラフィックを移動することがあります。
The IKEv2 NAT-T mechanism does not perform return routability checks. It simply uses the last seen source IP address used by the other peer as the destination address to which response packets are to be sent. An adversary can change those IP addresses and can cause the response packets to be sent to a wrong IP address. The situation is self-fixing when the adversary is no longer able to modify packets and the first packet with an unmodified IP address reaches the other peer. Mobility environments make this attack more difficult for an adversary since the attack requires the adversary to be located somewhere on the individual paths ({CoA1, ..., CoAn} towards the destination IP address), to have a shared path, or, if the adversary is located near the MOBIKE client, to follow the user mobility patterns. With IKEv2 NAT-T, the genuine client can cause third-party bombing by redirecting all the traffic pointed to him to a third party. As the MOBIKE protocol tries to provide equal or better security than IKEv2 NAT-T mechanism, it should protect against these attacks.
IKEv2のNAT-Tメカニズムは、リターン・ルータビリティチェックを実行しません。これは単に応答パケットが送信される先の宛先アドレスとして他のピアによって使用される最後から見たソースIPアドレスを使用します。敵は、それらのIPアドレスを変更することができ、応答パケットが間違ったIPアドレスに送信されることがあります。敵対者がもはやパケットを変更することができ、未修飾のIPアドレスを持つ最初のパケットは、他のピアに到達したときの状況は、自己固定されていません。攻撃が共有パスを有するように、個々のパス（宛先IPアドレスに向け{CoA1を、...、COAN}）上のどこかに位置する敵を必要とし、または、場合のでモビリティ環境は、敵のために、この攻撃がより困難に敵は、ユーザの移動パターンを追跡するために、MOBIKEクライアントの近くに位置しています。 IKEv2のNAT-Tを使用すると、本物のクライアントは、すべてのトラフィックが第三者に彼に指摘リダイレクトすることで、サードパーティ製の爆撃を引き起こす可能性があります。 MOBIKEプロトコルは、IKEv2のNAT-Tメカニズムよりも同等以上のセキュリティを提供しようとすると、それは、これらの攻撃から保護する必要があります。
There may be return routability information available from the other parts of the system too (as shown in Figure 3), but the checks done may have a different quality. There are multiple levels for return routability checks:
そこに（図3に示すように）あまりにもシステムの他の部分から入手可能なリターン・ルータビリティ情報であってもよいが、行わチェックは異なる品質を有していてもよいです。リターンルータビリティチェックのための複数のレベルがあります。
o None; no tests.
Oなし。何のテストはありません。
o A party willing to answer the return routability check is located along the path to the claimed address. This is the basic form of return routability check.
Oリターンルータビリティチェックに答えるために喜んでパーティがあったアドレスへの経路に沿って配置されます。これは、リターン・ルータビリティチェックの基本的な形です。
o There is an answer from the tested address, and that answer was authenticated and integrity- and replay-protected.
Oありテストアドレスからの答えは、その答えは、認証され、・インテグリティとリプレイで保護されました。
o There was an authenticated and integrity- and replay-protected answer from the peer, but it is not guaranteed to originate at the tested address or path to it (because the peer can construct a response without seeing the request).
Oがあり、ピアから認証され、・インテグリティとリプレイで保護された答えだったが、（ピアが要求を見ることなく応答を構築することができるので）、それをテストしたアドレスまたはパスで発生することが保証されていません。
The return routability checks do not protect against third-party bombing if the attacker is along the path, as the attacker can forward the return routability checks to the real peer (even if those packets are cryptographically authenticated).
攻撃者は、（これらのパケットが暗号的に認証されていても）実際のピアにリターンルータビリティチェックを転送できるよう、攻撃者は、パスに沿っている場合は、リターン・ルータビリティチェックは、サードパーティ製の爆撃を防ぐことはできません。
If the address to be tested is carried inside the MOBIKE payload, then the adversary cannot forward packets. Thus, third-party bombings are prevented (see Section 5.2.5).
テスト対象のアドレスがMOBIKEペイロードの内側に搭載されている場合、攻撃者はパケットを転送することはできません。したがって、サードパーティの爆撃（セクション5.2.5を参照のこと）が防止されます。
If the reply packet can be constructed without seeing the request packet (for example, if there is no nonce, challenge, or similar mechanism to show liveness), then the genuine peer can cause third-party bombing, by replying to those requests without seeing them at all.
応答パケットは、要求パケットを見ずに構築することができる場合（何ナンス、挑戦、または生存性を示すために同様のメカニズムが存在しない場合など）、そして本物のピアは見ずに、それらの要求に応答することで、サードパーティ製の爆撃を引き起こす可能性がありますそれらのすべて。
Other levels might only provide a guarantee that there is a node at the IP address that replied to the request. There is no indication as to whether or not the reply is fresh or whether or not the request may have been transmitted from a different source address.
他のレベルは要求に答えたIPアドレスのノードが存在するという保証を提供するかもしれません。応答が新鮮または要求が異なる送信元アドレスから送信されていてもよいかどうかであるか否かについての指摘はありません。
If MOBIKE has learned about new locations or verified the validity of a remote address through a return routability check, can this information be useful for other protocols?
MOBIKEは、新しい場所について学んだか、リターン・ルータビリティ・チェックをリモートアドレスの妥当性を検証している場合は、この情報は他のプロトコルのために役立つことができますか？
When the basic MOBIKE VPN scenario is considered, the answer is no. Transport and application layer protocols running inside the VPN tunnel are unaware of the outer addresses or their status.
基本的なMOBIKE VPNシナリオを考慮すると、答えはノーです。 VPNトンネル内で実行トランスポートおよびアプリケーション層プロトコルは、外部アドレスまたはその状態を知りません。
Similarly, IP-layer tunnel termination at a gateway rather than a host endpoint limits the benefits for "other protocols" that could be informed -- all application protocols at the other side are unaware of IPsec, IKE, or MOBIKE.
他方の側で全てのアプリケーションプロトコルのIPsec、IKE、又はMOBIKEを知らない - 同様に、ゲートウェイにIPレイヤのトンネル終端ではなくホストエンドポイントに通知することができる「他のプロトコル」の利益が制限されます。
However, it is conceivable that future uses or extensions of the MOBIKE protocol make such information distribution useful. For instance, if transport mode MOBIKE and SCTP were made to work together, it would potentially be useful for SCTP dynamic address reconfiguration [WIP-Ste06] to learn about the new addresses at the same time as MOBIKE. Similarly, various IP-layer mechanisms may make use of the fact that a return routability check of a specific type has been performed. However, care should be exercised in all these situations.
しかし、将来の用途やMOBIKEプロトコルの拡張は、このような情報配信を有用にすることが考えられます。トランスポートモードMOBIKEとSCTPが一緒に動作するようになされた場合例えば、それは潜在的にMOBIKEと同時に新しいアドレスについて学ぶためにSCTP動的アドレスの再構成[WIP-Ste06]のために有用であろう。同様に、様々なIPレイヤメカニズムは、特定のタイプのリターン・ルータビリティ・チェックが行われたという事実を利用することができます。しかし、ケアは、これらすべての状況で行使されなければなりません。
[WIP-Cro04] discusses the use of common locator information pools in a IPv6 multi-homing context; it assumes that both transport and IP-layer solutions are used in order to support multi-homing, and that it would be beneficial for different protocols to coordinate their results in some way, for instance, by sharing throughput information of address pairs. This may apply to MOBIKE as well, assuming it coexists with non-IPsec protocols that are faced with the same or similar multi-homing choices.
[WIP-Cro04]はIPv6のマルチホーミング文脈における共通ロケータ情報プールの使用について説明します。それは、トランスポートおよびIP層の両方のソリューションは、マルチホーミングを支援するために使用されること、及び異なるプロトコルは、アドレスペアのスループット情報を共有することによって、例えば、何らかの方法でその結果を調整することが有益であることを前提としています。これは、同一または類似のマルチホーミングの選択肢に直面していた非IPsecプロトコルと共存すると仮定すると、同様にMOBIKEに適用してもよいです。
Nevertheless, all of this is outside the scope of the current MOBIKE base protocol design and may be addressed in future work.
それにもかかわらず、このすべてが現在MOBIKEベースプロトコル設計の範囲外であり、将来の仕事に対処することができます。
If the return routability check fails, we need to tear down the IKE SA if we are using IKEv2 INFORMATIONAL exchanges to send return routability checks. On the other hand, return routability checks can only fail permanently if there was an attack by the other end; thus, tearing down the IKE SA is a suitable action in that case.
リターン・ルータビリティ・チェックが失敗した場合、我々はリターン・ルータビリティチェックを送信するためのIKEv2 INFORMATIONAL交換を使用している場合、IKE SAを取り壊すする必要があります。一方、もう一方の端による攻撃があった場合、ルータビリティ・チェックが唯一の永久に失敗する可能性があります返します。したがって、IKE SAを切断すると、その場合に好適アクションです。
There are some cases, where the return routability check temporarily fails, that need to be considered here. In the first case, there is no attacker, but the selected address pair stops working immediately after the address update, before the return routability check.
ここで考慮される必要があるリターン・ルータビリティチェックが一時的に失敗したいくつかのケースでは、あります。最初のケースでは、そこには攻撃者ではありませんが、選択されたアドレスのペアは、リターン・ルータビリティ・チェックの前に、アドレスを更新した後すぐに作業を停止します。
What happens is that the initiator performs the normal address update; it succeeds, and then the responder starts a return routability check. If the address pair has broken down before that, the responder will never get back the reply to the return routability check. The responder might still be using the old IP address pair, which could still work.
何が起こるかというと、イニシエータは、通常のアドレス更新を実行することです。それが成功した後、レスポンダは、リターン・ルータビリティチェックを開始します。アドレスのペアが、その前に故障した場合、応答者は、リターン・ルータビリティチェックに応答を取り戻すことはありません。レスポンダは、まだ、まだ仕事ができる古いIPアドレスのペアを、使用している場合があります。
The initiator might be still seeing traffic from the responder, but using the old address pair. The initiator should detect that this traffic is not using the latest address pair, and after a while it should start dead peer detection on the current address pair. If that fails, then it should find a new working address pair and update addresses to that. The responder should notice that the address pair was updated after the return routability check was started and change the ongoing return routability check to use the new address pair. The result of that return routability check needs to be discarded as it cannot be trusted; the packets were retransmitted to a different IP address. So normally the responder starts a new return routability check afterward with the new address pair.
イニシエータは、まだ応答者からのトラフィックを見ますが、古いアドレスのペアを使用している場合があります。イニシエータは、このトラフィックは、最新のアドレスのペアを使用していないことを検出する必要があり、しばらく後に、それは、現在のアドレスのペアで死んだピアの検出を開始する必要があります。それが失敗した場合、それは新しい作業アドレスのペアを見つけ、それにアドレスを更新する必要があります。レスポンダは、リターン・ルータビリティチェックが開始された後のアドレスのペアが更新されたことに気づくと、新しいアドレスのペアを使用するための継続的なリターンルータビリティチェックを変更する必要があります。そのリターン・ルータビリティチェックの結果は、それが信頼できないとして廃棄する必要があります。パケットが別のIPアドレスに再送されました。だから、通常の応答者は、新しいアドレスのペアで、その後、新たなリターン・ルータビリティチェックを開始します。
The second case is where there is an attacker along the path modifying the IP addresses. The peers will detect this as NAT and will enable NAT-T recovery of changes in the NAT mappings. If the attacker is along the path long enough for the return routability check to succeed, then the normal recovery of changes in the NAT mappings will take care of the problem. If the attacker disappears before return routability check is finished, but after the update, we have a case similar to the last. The only difference is that now the dead peer detection started by the initiator will succeed because the responder will reply to the addresses in the headers, not the current address pair. The initiator will then detect that the NAT mappings are changed, and it will fix the situation by doing an address update.
IPアドレスを変更する経路に沿って、攻撃者がある場合に第二の場合です。ピアはNATとしてこれを検出し、NATマッピングの変更のNAT-Tの回復を可能にします。攻撃者は、リターン・ルータビリティチェックが成功するために十分な長さの経路に沿っている場合は、NATマッピングの変更の正常な回復は、問題の世話をします。攻撃者は、リターン・ルータビリティチェックが終了する前に消えますが、更新後、我々は最後に類似ケースを持っている場合。唯一の違いは、レスポンダが、ヘッダーではなく、現在のアドレスペアのアドレスに返信されますので、開始剤によって開始された今、死んだピアの検出が成功するということです。イニシエータは、NATマッピングが変更されたことを検出し、それがアドレス更新を行うことで、状況を修正します。
The important thing for both of these cases is that the initiator needs to see that the responder is both alive and synchronized with initiator address pair updates. That is, it is not enough that the responder is sending traffic to an initiator; it must also be using the correct IP addresses before the initiator can believe it is alive and synchronized. From the implementation point of view, this means that the initiator must not consider packets having wrong IP addresses as packets that prove the other end is alive, i.e., they do not reset the dead peer detection timers.
これらの例の両方のために重要なことは、イニシエータがレスポンダが生きていると開始アドレスのペアの更新と同期の両方であることを確認する必要があるということです。つまり、レスポンダがイニシエータにトラフィックを送信していることは十分ではありません、です。イニシエータは、それが生きていると同期である信じることができる前に、それはまた、正しいIPアドレスを使用する必要があります。実装の観点からは、これはイニシエータがもう一方の端が生きていることを証明するパケット、すなわちとして間違ったIPアドレスを持つパケットを考慮していなければならないことを意味し、彼らは死んだピア検出タイマーをリセットしません。
The working group selected to use IKEv2 INFORMATIONAL exchanges as a return routability check, but included a random cookie to prevent redirection by an authenticated attacker. Return routability checks are performed by default before moving the traffic. However, these tests are optional. Nodes may also perform these tests upon their own initiative at other times.
ワーキンググループは、リターン・ルータビリティチェックとしてのIKEv2 INFORMATIONAL交換を使用することを選択したが、認証された攻撃者によってリダイレクトを防ぐために、ランダムなクッキーが含まれています。リターン・ルータビリティチェックはトラフィックを移動する前に、デフォルトで実行されています。しかし、これらのテストはオプションです。ノードはまた、他の回で、独自の取り組みにより、これらのテストを行うことができます。
It is worth noting that the return routability check in MOBIKE is different from Mobile IPv6 [RFC3775], which does not perform return routability operations between the mobile node and its home agent at all.
MOBIKEにおけるリターン・ルータビリティ・チェックは、すべてのモバイルノードとそのホームエージェントとの間の往復経路の操作を実行していないモバイルIPv6 [RFC3775]、異なっていることは注目に値します。
The current MOBIKE design is focused only on the VPN type usage and tunnel mode. Transport mode behavior would also be useful and might be discussed in future documents.
現在MOBIKEデザインは唯一のVPNタイプの使用状況とトンネルモードに焦点を当てています。トランスポートモードの動作も有用であろうと、将来の文書で議論される可能性があります。
In order for MOBIKE to function, both peers must implement the MOBIKE extension of IKEv2. If one of the peers does not support MOBIKE, then, whenever an IP address changes, IKEv2 will have to be re-run in order to create a new IKE SA and the respective IPsec SAs. In MOBIKE, a peer needs to be confident that its address change messages are understood by the other peer. If these messages are not understood, it is possible that connectivity between the peers is lost.
MOBIKEが機能するためには、両方のピアは、IKEv2ののMOBIKE拡張を実装する必要があります。ピアの1つは、MOBIKEをサポートしていない場合は、その後、いつでもIPアドレスの変更、IKEv2のは、新しいIKE SAとそれぞれのIPsec SAを作成するために再実行する必要があります。 MOBIKEでは、ピアは、アドレス変更メッセージが他のピアによって理解されていることを確信する必要があります。これらのメッセージが理解されていない場合は、ピア間の接続が失われている可能性があります。
One way to ensure that a peer receives feedback on whether its messages are understood by the other peer is to use IKEv2 messaging for MOBIKE and to mark some messages as "critical". According to the IKEv2 specification, either such messages have to be understood by the receiver, or an error message has to be returned to the sender.
ピアは、そのメッセージが他のピアによって理解されているかどうかについてのフィードバックを受けることを確保するための一つの方法は、MOBIKEのためのIKEv2メッセージングを使用すると、「重要」として、いくつかのメッセージをマークすることです。 IKEv2の仕様によれば、そのようなメッセージのいずれかが受信機によって理解されなければならない、またはエラー・メッセージが送信者に返さなければなりません。
A second way to ensure receipt of the above-mentioned feedback is by using Vendor ID payloads that are exchanged during the initial IKEv2 exchange. These payloads would then indicate whether or not a given peer supports the MOBIKE protocol.
上記フィードバックの受信を確実にする第二の方法は、初期のIKEv2交換の間に交換されるベンダーIDペイロードを使用することです。これらのペイロードは、与えられたピアがMOBIKEプロトコルをサポートしているかどうかを示すことになります。
A third approach would use the Notify payload to indicate support of MOBIKE extension. Such Notify payloads are also used for indicating NAT traversal support (via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads).
第三のアプローチは、MOBIKE拡張のサポートを示すために、通知ペイロードを使用します。そのような通知ペイロードはまた、（NAT_DETECTION_SOURCE_IPとNAT_DETECTION_DESTINATION_IPペイロードを介して）NATトラバーサルのサポートを示すために使用されます。
Both a Vendor ID and a Notify payload may be used to indicate the support of certain extensions.
ベンダID及び通知ペイロードの両方が特定の拡張子のサポートを示すために使用されてもよいです。
Note that a MOBIKE peer could also attempt to execute MOBIKE opportunistically with the critical bit set when an address change has occurred. The drawback of this approach is, however, that an unnecessary message exchange is introduced.
MOBIKEピアは、アドレスの変更が発生した場合、重要なビットセットで日和見MOBIKEを実行しようとする可能性があることに注意してください。このアプローチの欠点は、不必要なメッセージ交換が導入されることがあります。
Although Vendor ID payloads and Notify payloads are technically equivalent, Notify payloads are already used in IKEv2 as a capability negotiation mechanism. Hence, Notify payloads are used in MOBIKE to indicate support of MOBIKE protocol.
ベンダーIDペイロード及び通知ペイロードは技術的に同等ですが、ペイロードがすでに能力交渉メカニズムとしてIKEv2の中で使用されている通知。したがって、通知ペイロードは、MOBIKEプロトコルのサポートを示すためにMOBIKEに使用されます。
Also, as the information of the support of MOBIKE is not needed during the IKE_SA_INIT exchange, the indication of the support is done inside the IKE_AUTH exchange. The reason for this is the need to keep the IKE_SA_INIT messages as small as possible so that they do not get fragmented. IKEv2 allows that the responder can do stateless processing of the first IKE_SA_INIT packet and request a cookie from the other end if it is under attack. To mandate the responder to be able to reassemble initial IKE_SA_INIT packets would not allow fully stateless processing of the initial IKE_SA_INIT packets.
MOBIKEの支援の情報は、IKE_SA_INIT交換中に必要されていないとしても、サポートの表示はIKE_AUTH交換の内部で行われます。この理由は、彼らが断片化取得しないように、できるだけ小さくIKE_SA_INITメッセージを維持する必要があります。 IKEv2のは、応答者が最初のIKE_SA_INITパケットのステートレスな処理を行うと、それが攻撃を受けている場合は、他の端からクッキーを要求できることができます。レスポンダを強制するには、最初のIKE_SA_INITパケットの完全ステートレスな処理を許可しないだろう最初のIKE_SA_INITパケットを再構成することができるようにします。
As IKEv2 has a window of outgoing messages, and the sender is not allowed to violate that window (meaning that if the window is full, then the sender cannot send packets), it can cause some complications to path testing. Another complication created by IKEv2 is that once the message is created and sent to the other end, it cannot be modified in its future retransmissions. This makes it impossible to know what packet actually reached the other end first. We cannot use IP headers to find out which packet reached the other end first because if the responder gets retransmissions of the packet it has already processed and replied to (and those replies might have been lost due unidirectional address pair), it will retransmit the previous reply using the new address pair of the request. Because of this, it might be possible that the responder has already used the IP address information from the header of the previous packet, and the reply packet ending up at the initiator has a different address pair.
IKEv2のは（ウィンドウがいっぱいになった場合は、送信者がパケットを送信することができないことを意味する）送信メッセージのウィンドウを持っており、送信者がそのウィンドウに違反することは許されないとして、それはパスのテストにいくつかの合併症を引き起こす可能性があります。 IKEv2のによって作成されたもう一つの合併症は、メッセージが作成され、もう一方の端に送信されると、それは今後の再送信で変更することができないということです。これは不可能実際には最初のもう一方の端に到達したものをパケット知ることができます。我々は、それが以前に再送信する最初のもう一方の端に到達したレスポンダは、パケットの再送を取得する場合、それはすでに処理されたためとの回答（およびこれらの応答は、単方向のアドレスのペアによって失われている可能性があります）どのパケットを見つけるためにIPヘッダーを使用することはできませんリクエストの新しいアドレスのペアを使用して返信します。このため、レスポンダが既に前のパケットのヘッダからIPアドレス情報を使用しており、イニシエータで終わる返信パケットは異なるアドレス・ペアを有することが可能であるかもしれません。
Another complication comes from NAT-T. The current IKEv2 document says that if NAT-T is enabled, the node not behind NAT SHOULD detect if the IP address changes in the incoming authenticated packets and update the remote peers' addresses accordingly. This works fine with NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs the ability to probe other address pairs without breaking the old one.
もう一つの合併症は、NAT-Tから来ています。現在のIKEv2文書がNAT-Tが有効になっている場合ではなく、NATの背後にあるノードが着信認証されたパケットであればIPアドレスの変更を検出し、それに応じて、リモートピアのアドレスを更新する必要があることを述べています。これは、NAT-Tで正常に動作しますが、MOBIKEは古いものを壊すことなく、他のアドレスのペアを精査する能力が必要であるとして、それは、MOBIKEでいくつかの合併症を引き起こします。
One approach to fix this would be to add a completely new protocol that is outside the IKE SA message id limitations (window code), outside identical retransmission requirements, and outside the dynamic address updating of NAT-T.
この問題を解決する一つのアプローチは、同一の再送要求外側、およびNAT-Tの動的アドレス更新の外側に、IKE SAメッセージIDの制限（ウィンドウコード）の外側にある全く新しいプロトコルを追加することであろう。
Another approach is to make the protocol so that it does not violate window restrictions and does not require changing the packet on retransmissions, and change the dynamic address updating of NAT-T to "MUST NOT" for IKE SA packets if MOBIKE is used. In order not to violate window restrictions, the addresses of the currently ongoing exchange need to be changed to test different paths. In order not to require that the packet be changed after it is first sent requires that the protocol restart from the beginning in case the packet was retransmitted to different addresses (because the sender does not know which packet the responder got first, i.e., which IP addresses it used).
別のアプローチは、ウィンドウの制限に違反しないと再送信にパケットを変更する必要はありません、とMOBIKEを使用する場合は、「MUST NOT」IKE SAパケットのにNAT-Tの動的アドレスの更新を変更するようにプロトコルを作ることです。ウィンドウの制限に違反しないようにするためには、現在継続中の交流のアドレスが異なるパスをテストするために変更する必要があります。それが最初に送信された後、パケットが変更されることを必要としないようにするために必要と送信者はすなわち、レスポンダが最初に得たどのパケットを知っていないため、パケットが（別のアドレスに再送信された場合には最初からプロトコルの再起動、IP ）それが使用されるアドレス。
The working group decided to use normal IKEv2 exchanges for path testing and decided to change the dynamic address updating of NAT-T to MUST NOT for IKE SA packets; a new protocol outside of IKEv2 was not adopted.
ワーキンググループは、パス試験のために通常のIKEv2交換を使用することを決定し、NAT-Tの動的アドレス更新を変更することを決定しないようにIKE SAパケットのなければなりません。 IKEv2の外の新しいプロトコルが採用されませんでした。
The IP address change notifications can be sent either via an informational exchange already specified in IKEv2, or via a MOBIKE-specific message exchange. Using an informational exchange has the main advantage that it is already specified in the IKEv2 protocol and implementations can already incorporate the functionality.
IPアドレス変更通知はすでにIKEv2の中で指定した情報交換によって、またはMOBIKE固有のメッセージ交換のいずれかを介して送信することができます。情報交換を使用することは、既にのIKEv2プロトコルで指定され、実装が既に機能を組み込むことができる主な利点を有します。
Another question is the format of the address update notifications. The address update notifications can include multiple addresses, of which some may be IPv4 and some IPv6 addresses. The number of addresses is most likely going to be limited in typical environments (with less than 10 addresses). The format may need to indicate a preference value for each address. The format could either contain a preference number that determines the relative order of the addresses or could simply be an ordered list of IP addresses. If using preference numbers, then two addresses can have the same preference value; an ordered list avoids this situation.
もう一つの問題は、アドレス更新通知の形式です。アドレス更新通知は、一部は、IPv4およびいくつかのIPv6アドレスであってもよい複数のアドレスを含むことができます。アドレスの数は、最も可能性が高い（10個の未満アドレスを持つ）一般的な環境に制限されることになるだろう。フォーマットは、アドレスごとに嗜好値を指示する必要があるかもしれません。フォーマットは、アドレスの相対的な順序を決定する、または単にIPアドレスの順序付けられたリストとすることができる優先順位番号を含むことができるいずれか。好みの番号を使用している場合、2つのアドレスが同じ優先度の値を持つことができます。順序付きリストは、このような状況を回避できます。
Load balancing is currently outside the scope of MOBIKE; however, future work might include support for it. The selected format needs to be flexible enough to include additional information in future versions of the protocol (e.g., to enable load balancing). This may be realized with an reserved field, which can later be used to store additional information. As other information may arise that may have to be tied to an address in the future, a reserved field seems like a prudent design in any case.
負荷分散は、MOBIKEの範囲外で、現在あります。しかし、将来の仕事はそれのためのサポートが含まれる場合があります。選択されたフォーマット（例えば、負荷バランシングを可能にするために）、プロトコルの将来のバージョンに追加の情報を含むのに十分に柔軟である必要があります。これは、後に追加情報を格納するために使用できる予約フィールドを使用して実現することができます。その他の情報は、それが将来のアドレスに結び付けなければならないことが発生する可能性があるとして、予約フィールドは、どのような場合でも、慎重なデザインのように思えます。
There are two basic formats that place IP address lists into a message. One includes each IP address as separate payload (where the payload order indicates the preference order, or the payload itself might include the preference number). Alternatively, we can put the IP address list as one payload to the exchange, and that one payload will then have an internal format that includes the list of IP addresses.
メッセージにIPアドレスリストを置く二つの基本的な形式があります。一つは、別個のペイロードとして各IPアドレスは、（ペイロードの順序は優先順位を示し、またはペイロード自体は、優先順位番号を含むかもしれません）。また、我々は、IPアドレスのリストを含んでいる内部形式を持つことになります為替への1つのペイロード、およびその1つのペイロードとしてIPアドレスのリストを置くことができます。
Having multiple payloads, each one carrying one IP address, makes the protocol probably easier to parse, as we can already use the normal IKEv2 payload parsing procedures. It also offers an easy way for the extensions, as the payload probably contains only the type of the IP address (or the type is encoded to the payload type), and the IP address itself. As each payload already has a length field associated to it, we can detect if there is any extra data after the IP address. Some implementations might have problems parsing more than a certain number of IKEv2 payloads, but if the sender sends them in the most preferred first, the receiver can only use the first addresses it was willing to parse.
複数のペイロードを持つ、1つのIPアドレスを運ぶそれぞれが、我々はすでに通常のIKEv2ペイロード解析手順を使用することができるよう、解析するプロトコルは、おそらく簡単になります。ペイロードはおそらく唯一のIPアドレス（またはタイプは、ペイロードタイプに符号化された）の種類、およびIPアドレス自体が含まれているとして、それはまた、拡張のための簡単な方法を提供しています。各ペイロードはすでにそれに関連した長さフィールドを持っているとして、IPアドレスの後に余分なデータがある場合、我々は検出することができます。一部の実装では、IKEv2のペイロードの一定数以上を解析する問題を抱えているかもしれませんが、送信者が最も好ましい最初にそれらを送信する場合、受信機は、解析して喜んでいた最初のアドレスを使用することができます。
Having all IP addresses in one big MOBIKE-specified internal format provides more compact encoding and keeps the MOBIKE implementation more concentrated to one module.
一つの大きなMOBIKE、指定された内部形式ですべてのIPアドレスを持つことは、よりコンパクトなエンコーディングを提供し、一つのモジュールにより濃縮MOBIKE実装を保持します。
Another choice is which type of payloads to use. IKEv2 already specifies a Notify payload. It includes some extra fields (SPI size, SPI, protocol, etc.), which gives 4 bytes of the extra overhead, and there is the notification data field, which could include the MOBIKE-specific data.
もう一つの選択肢は、ペイロードのタイプを使用するかです。 IKEv2のは、すでに通知ペイロードを指定します。これは、余分なオーバーヘッドの4つのバイトを与えるいくつかの余分なフィールド（SPIサイズ、SPI、プロトコルなど）を含み、及びMOBIKE固有のデータを含むことができる通知データフィールドが、存在します。
Another option would be to have a custom payload type, which would then include the information needed for the MOBIKE protocol.
別のオプションは、MOBIKEプロトコルのために必要な情報が含まれるカスタムペイロードタイプを、持っているだろう。
The working group decided to use IKEv2 Notify payloads, and put only one data item per notify. There will be one Notify payload for each item to be sent.
ワーキンググループは、IKEv2のは、ペイロードを通知し、通知ごとに1つだけのデータ項目を入れて使用することを決めました。 1が送信する各項目のペイロードに通知があります。
Because the initiator decides all address updates, the initiator needs to know all the addresses used by the responder. The responder also needs that list in case it happens to move to an address not known by the initiator, and it needs to send an address update notification to the initiator. It might need to try different addresses for the initiator.
イニシエータがすべてのアドレスの更新を決定しているため、イニシエータは、レスポンダが使用するすべてのアドレスを知っている必要があります。応答者はまた、イニシエータによって知られていないアドレスに移動するために起こる場合には、そのリストを必要とし、それがイニシエータにアドレス更新通知を送信する必要があります。これは、イニシエータの異なるアドレスを試してみる必要があるかもしれません。
MOBIKE could send the whole peer address list every time any of the IP addresses change (addresses are added or removed, the order changes, or the preferred address is updated) or an incremental update. Sending incremental updates provides more compact packets (meaning we can support more IP addresses), but on the other hand this approach has more problems in the synchronization and packet reordering cases. That is, incremental updates must be processed in order, but for full updates we can simply use the most recent one and ignore old ones, even if they arrive after the most recent one (IKEv2 packets have a message ID that is incremented for each packet; thus, it is easy to know the sending order).
MOBIKEは、全体のピアアドレスのリストにIPアドレスのいずれかが変化するたびに（アドレスが追加または削除され、順序の変更、または優先アドレスが更新されます）または増分更新を送信することができます。増分更新を送信すると（私たちはより多くのIPアドレスをサポートできることを意味）よりコンパクトなパケットを提供していますが、一方で、このアプローチは、同期、パケット並べ替えの場合、より多くの問題を抱えています。これは、増分更新は順番に処理されなければならないが、完全な更新のために、私たちは、単に最新のものを使用して、古いものを無視することができ、彼らは最新のものの後に到着した場合でも（IKEv2のパケットは、パケットごとにインクリメントされるメッセージIDを持っています、したがって、）、送信順序を知ることは容易です。
The working group decided to use a protocol format where both ends send a full list of their addresses to the other end, and that list overwrites the previous list. To support NAT-T, the IP addresses of the received packet are considered as one address of the peer, even when they are not present in the list.
ワーキンググループは、両端がもう一方の端にそれらのアドレスの完全なリストを送信するプロトコルフォーマットを使用することを決定し、そのリストには、前のリストを上書きします。 NAT-Tをサポートするために、受信したパケットのIPアドレスは、それらがリストに存在しない場合でも、ピアの一つのアドレスとして考えられています。
As all the packets are already authenticated by IKEv2, there is no risk that any attackers would undetectedly modify the contents of the packets. The IP addresses in the IP header of the packets are not authenticated; thus, the protocol defined must take care that they are only used as an indication that something might be different, and that they do not cause any direct actions, except when doing NAT traversal.
すべてのパケットがすでにのIKEv2によって認証されているように、任意の攻撃者がundetectedlyパケットの内容を変更することをリスクはありません。パケットのIPヘッダ内のIPアドレスが認証されていません。このように、彼らは唯一の何かが違うかもしれないことを示す指標として使用されていること、そして、彼らはNATトラバーサルを行っている場合を除き、任意の直接行動を起こさないことを注意しなければならない定義されたプロトコル。
An attacker can also spoof ICMP error messages in an effort to confuse the peers about which addresses are not working. At worst, this causes denial of service and/or the use of non-preferred addresses.
攻撃者はまた、アドレスが機能していないされているかについてのピアを混乱させるための努力のICMPエラーメッセージを偽装することができます。最悪の場合、これはサービスおよび/または非優先アドレスの使用の拒否の原因となります。
One type of attack that needs to be taken care of in the MOBIKE protocol is the bombing attack type. See [RFC4225] and [Aur02] for more information about flooding attacks.
MOBIKEプロトコルでの世話をする必要があり、攻撃の一つのタイプは、爆撃の攻撃タイプです。 [RFC4225]と[Aur02]フラッディング攻撃の詳細については、を参照してください。
See the security considerations section of [RFC4555] for more information about security considerations of the actual protocol.
実際のプロトコルのセキュリティに関する考慮事項の詳細については、[RFC4555]のセキュリティの考慮事項のセクションを参照してください。
This document is the result of discussions in the MOBIKE working group. The authors would like to thank Jari Arkko, Pasi Eronen, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, Udo Schilcher, Tom Henderson, Andreas Pashalidis, and Maureen Stillman for their input.
この文書では、MOBIKEワーキンググループでの議論の結果です。著者はヤリArkko、パシEronen、フランシスデュポン、モハンパルタサラティ、ポール・ホフマン、ビルゾンマーフェルト、ジェームズ・ケンプ、ビジェイDevarapalli、アトゥール・シャルマ、ボラAkyol、ジョー・タッチ、ウドSchilcher、トム・ヘンダーソン、アンドレアスPashalidis、とモーリーンに感謝したいと思います彼らの入力のためのスティルマン。
We would like to particularly thank Pasi Eronen for tracking open issues on the MOBIKE mailing list. He helped us make good progress on the document.
私たちは、特にMOBIKEメーリングリストに未解決の問題を追跡するためのパシEronenに感謝したいと思います。彼は、私たちは、ドキュメントの良い進歩をさせてくれました。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", In Proc. 18th Annual Computer Security Applications Conference, pages 78-87, Las Vegas, NV USA, December 2002.
PROCで【Aur02]オーラ、T.、卵、M.、およびJ. Arkko、 "インターネットロケーション管理のセキュリティ"、。第18回コンピュータセキュリティアプリケーションの会議、ページ78-87、ラスベガス、ネバダ州、アメリカ、2002年12月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]マクドナルド、D.、メッツ、C.、およびB. Phanさん、 "PF_KEY鍵管理API、バージョン2"、RFC 2367、1998年7月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
"IPsecでストリーム制御伝送プロトコル（SCTP）の使用に" [RFC3554] Bellovin氏、S.、Ioannidis、J.、Keromytis、A.、およびR.スチュワート、RFC 3554、2003年7月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[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月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]ムーア、N.、 "IPv6の楽観重複アドレス検出（DAD）"、RFC 4429、2006年4月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[WIP-Ark06] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Work in Progress, June 2006.
[WIP-Ark06] Arkko、J.およびI. Beijnum、 "障害検出およびIPv6マルチホーミングのためのロケータペア探索プロトコル"、進歩、2006年6月での作業。
[WIP-Cro04] Crocker, D., "Framework for Common Endpoint Locator Pools", Work in Progress, February 2004.
[WIP-Cro04]クロッカー、D.、 "一般的なエンドポイントロケータプールのフレームワーク"、進歩、2004年2月に作業。
[WIP-Nik06] Nikander, P., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, June 2006.
[WIP-Nik06] Nikander、進歩、2006年6月に、仕事P.、「ホストアイデンティティプロトコルとエンドホストモビリティとマルチホーミング」。
[WIP-Ste06] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Work in Progress, June 2006.
[WIP-Ste06]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）動的アドレスの再構成"、進歩、2006年6月での作業。
[WIP-Sti06] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, June 2006.
[WIP-Sti06] Stiemerling、M.、Tschofenig、H.、アウン、C.、およびE.デイヴィス、 "NAT /ファイアウォールNSISシグナリング層プロトコル（NSLP）"、進歩、2006年6月での作業。
Authors' Addresses
著者のアドレス
Tero Kivinen Safenet, Inc. Fredrikinkatu 47 HELSINKI FI-00100 FI
TERO Kivinenセーフネット株式会社Fredrikinkatu 47 00100 HELSINKI FI-FI
EMail: kivinen@safenet-inc.com
メールアドレス：kivinen@safenet-inc.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigシーメンスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com
電子メール：Hannes.Tschofenig@siemens.com URI：http://www.tschofenig.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。