RFC3776 日本語訳
3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodesand Home Agents. J. Arkko, V. Devarapalli, F. Dupont. June 2004. (Format: TXT=87076 bytes) (Updated by RFC4877) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Arkko
Request for Comments: 3776 Ericsson
Category: Standards Track V. Devarapalli
Nokia Research Center
F. Dupont
GET/ENST Bretagne
June 2004
Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3776年のエリクソンカテゴリ: 規格道はENSTブルターニュ2004年6月にDevarapalliノキアのリサーチセンターF.デュポンに対して/を届けます。
Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents
モバイルノードとホームのエージェントの間で合図するモバイルIPv6を保護するのにIPsecを使用します。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
モバイルIPv6は、保護するのにホームのエージェントとモバイルノードの間で合図しながら、IPsecを使用します。 モバイルIPv6元にした文書はこれらのノードが続かなければならない主な要件を定義します。 このドキュメントは、正しい注文により多くの深さでこれらの要件について議論して、中古のパケット・フォーマットを例証して、適当な構成手順を説明して、実装がどうパケットを処理できるかを示しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Binding Updates and Acknowledgements . . . . . . . . . 5
3.2 Return Routability Signaling . . . . . . . . . . . . . 7
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 8
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 10
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 10
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15
5. Example Configurations . . . . . . . . . . . . . . . . . . . 16
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . 5 3。 アップデートと承認. . . . . . . . . 5 3.2を縛るパケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . . 5 3.1が接頭語発見. . . . . . . . . . . . . . . . . . . 8 3.4有効搭載量パケット. . . . . . . . . . . . . . . . . . . 9 4をRoutabilityシグナリング. . . . . . . . . . . . . 7 3.3に返します。 要件. . . . . . . . . . . . . . . . . . . . . . . . 9 4.1の義務的なサポート. . . . . . . . . . . . . . . . . . 10 4.2方針要件. . . . . . . . . . . . . . . . . 10 4.3IPsecは.155を合わせる処理. . . . . . . . . . . . . . 13 4.4動力について議定書の中で述べます。 例の構成. . . . . . . . . . . . . . . . . . . 16
Arkko, et al. Standards Track [Page 1] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[1ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 18
5.2.1 Binding Updates and Acknowledgements . . . . . . 18
5.2.2 Return Routability Signaling . . . . . . . . . . 19
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 21
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Binding Updates and Acknowledgements . . . . . . 22
5.3.2 Return Routability Signaling . . . . . . . . . . 23
5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24
5.3.4 Payload Packets . . . . . . . . . . . . . . . . 25
6. Processing Steps within a Node . . . . . . . . . . . . . . . 25
6.1 Binding Update to the Home Agent . . . . . . . . . . . 25
6.2 Binding Update from the Mobile Node . . . . . . . . . 26
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 27
6.4 Binding Acknowledgement from the Home Agent . . . . . 28
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 29
6.6 Home Test Init from the Mobile Node . . . . . . . . . 30
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 30
6.8 Home Test from the Home Agent . . . . . . . . . . . . 31
6.9 Prefix Solicitation Message to the Home Agent . . . . 31
6.10 Prefix Solicitation Message from the Mobile Node . . . 31
6.11 Prefix Advertisement Message to the Mobile Node . . . 32
6.12 Prefix Advertisement Message from the Home Agent . . . 32
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 32
6.14 Payload Packet from the Mobile Node . . . . . . . . . 32
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 32
6.16 Payload Packet from the Home Agent . . . . . . . . . . 32
6.17 Establishing New Security Associations . . . . . . . . 32
6.18 Rekeying Security Associations . . . . . . . . . . . . 33
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 34
7. Implementation Considerations . . . . . . . . . . . . . . . 35
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . 37
10 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1 Normative References . . . . . . . . . . . . . . . . . 38
10.2 Informative References . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 40
5.1 形式. . . . . . . . . . . . . . . . . . . . . . . . 17 5.2拘束力がある手動の構成. . . . . . . . . . . . . . . . . 18 5.2.1のアップデートと承認. . . . . . 18 5.2.2は.3接頭語発見. . . . . . . . . . . . . . . . 20 5.2.4の有効搭載量パケットをRoutabilityシグナリング. . . . . . . . . . 19 5.2に返します…; .215.3 拘束力があるダイナミックな合わせ. . . . . . . . . . . . . . . . . . . . 22 5.3る.1のアップデートと承認. . . . . . 22 5.3.2は.3接頭語発見. . . . . . . . . . . . . . . . 24 5.3.4の有効搭載量パケット. . . . . . . . . . . . . . . . 25 6をRoutabilityシグナリング. . . . . . . . . . 23 5.3に返します。 ホームエージェント.256.2結合へのノード. . . . . . . . . . . . . . . 25 6.1の拘束力がある最新版の中の処理ステップはモバイルノード. . . . . . . . . 26 6.3の拘束力がある承認からモバイルノード. . . . . . 27 6.4まで拘束力があるホームのエージェント. . . . . 28 6.5ホームテストイニットからホームのエージェント. . . . . . . . . . . 29 6.6ホームテストイニットまでの承認をモバイルノード. . . . . . . . . 30 6.7ホームテストからモバイルノード. . . . . . . . . . . . . 30 6までアップデートします; 8ホームモバイルノード. . . 31 6.11接頭語広告メッセージからモバイルノード. . . 32 6へのホームエージェント.316.9接頭語懇願メッセージからホームエージェント.31 6.10接頭語懇願メッセージまでのテスト; ホムからの12接頭語広告モバイルノード.32 6.15有効搭載量パケットからモバイルノード.32 6.16有効搭載量パケットへのホームエージェント.32 6.13有効搭載量パケットからホームエージェント.32 6.14有効搭載量パケットまでのメッセージ新しいセキュリティ協会. . . . . . . . 32 6.18Rekeyingセキュリティ協会. . . . . . . . . . . . 33 6.19運動とダイナミックな合わせ. . . . . . . . . . . . . 34 7ることを確立するeエージェント. . . . . . . . . . 32 6.17。 実装問題. . . . . . . . . . . . . . . 35 7.1IPsec. . . . . . . . . . . . . . . . . . . . . . . . 35 7.2IKE. . . . . . . . . . . . . . . . . . . . . . . . . 36 7.3はスタックで.378に突き当たります。 IANA問題. . . . . . . . . . . . . . . . . . . . 37 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . 37 10参照. . . . . . . . . . . . . . . . . . . . . . . . . 38 10.1引用規格. . . . . . . . . . . . . . . . . 38 10.2の有益な参照. . . . . . . . . . . . . . . . 38 11。 承認. . . . . . . . . . . . . . . . . . . . . . 39 12。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 39 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 40
Arkko, et al. Standards Track [Page 2] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[2ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
1. Introduction
1. 序論
This document illustrates the use of IPsec in securing Mobile IPv6 [7] traffic between mobile nodes and home agents. In Mobile IPv6, a mobile node is always expected to be addressable at its home address, whether it is currently attached to its home link or is away from home. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a mobile node is at home, packets addressed to its home address are routed to the mobile node's home link.
このドキュメントはモバイルIPv6[7]がモバイルノードとホームのエージェントの間のトラフィックであると機密保護することにおけるIPsecの使用を例証します。 モバイルIPv6では、いつもモバイルノードがホームアドレスでアドレス可能であると予想されます、それが現在、ホームのリンクに添付されるか、または家にいないことにかかわらず。 「ホームアドレス」はホームのリンクでホームサブネット接頭語の中でモバイルノードに割り当てられたIPアドレスです。 モバイルノードがホームにある間、ホームアドレスに扱われたパケットはモバイルノードのホームのリンクに発送されます。
While a mobile node is attached to some foreign link away from home, it is also addressable at a care-of address. A care-of address is an IP address associated with a mobile node that has a subnet prefix from a particular foreign link. The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message.
モバイルノードがまたホームから遠くでは、それもアドレス可能である、ある外国リンクに添付される、注意、-、アドレス 注意、-、アドレス、サブネット接頭語を持っているモバイルノードに関連しているIPアドレスは特定の外国リンクから来ていますか? そして、モバイルノードのホームアドレスの間の協会、注意、-、アドレスはモバイルノードのための「結合」として知られています。 モバイルノードがホームから遠くに登録する、それ、初期医療、-、ルータがオンな状態でホームのリンクを扱ってください、モバイルノードのための「ホームのエージェント」として機能するようこのルータに要求して。 モバイルノードは、「拘束力があるアップデート」メッセージをホームのエージェントに送ることによって、この拘束力がある登録を実行します。 ホームのエージェントは、「拘束力がある承認」メッセージを返すことによって、モバイルノードに答えます。
Any other nodes communicating with a mobile node are referred to as "correspondent nodes". Mobile nodes can provide information about their current location to correspondent nodes, again using Binding Updates and Acknowledgements. Additionally, return routability test is performed between the mobile node, home agent, and the correspondent node in order to authorize the establishment of the binding. Packets between the mobile node and the correspondent node are either tunneled via the home agent, or sent directly if a binding exists in the correspondent node for the current location of the mobile node.
モバイルノードとコミュニケートするいかなる他のノードも「通信員ノード」と呼ばれます。 再びBinding UpdatesとAcknowledgementsを使用して、モバイルノードはそれらの現在の位置の情報を通信員ノードに備えることができます。 さらに、リターンroutabilityテストは、結合の設立を認可するためにモバイルノードと、ホームのエージェントと、通信員ノードの間で実行されます。 結合がモバイルノードの現在の位置のための通信員ノードに存在しているなら、モバイルノードと通信員ノードの間のパケットをホームのエージェントを通してトンネルを堀るか、または直接送ります。
Mobile IPv6 tunnels payload packets between the mobile node and the home agent in both directions. This tunneling uses IPv6 encapsulation [6]. Where these tunnels need to be secured, they are replaced by IPsec tunnels [2].
モバイルIPv6はモバイルノードとホームのエージェントの間のペイロードパケットに両方の方向にトンネルを堀ります。 このトンネリングはIPv6カプセル化[6]を使用します。 これらのトンネルが、機密保護される必要があるところでは、それらをIPsecトンネル[2]に取り替えます。
Mobile IPv6 also provides support for the reconfiguration of the home network. Here, the home subnet prefixes may change over time. Mobile nodes can learn new information about home subnet prefixes through the "prefix discovery" mechanism.
また、モバイルIPv6はホームネットワークの再構成のサポートを提供します。 ここで、ホームサブネット接頭語は時間がたつにつれて、変化するかもしれません。 モバイルノードは「接頭語発見」メカニズムを通してホームサブネット接頭語に関する新情報を学ぶことができます。
This document discusses security mechanisms for the control traffic between the mobile node and the home agent. If this traffic is not protected, mobile nodes and correspondent nodes are vulnerable to man-in-the-middle, hijacking, passive wiretapping, impersonation, and
このドキュメントはモバイルノードとホームのエージェントの間のコントロールトラフィックのためにセキュリティー対策について議論します。 そしてこのトラフィックが保護されないなら、モバイルノードと通信員ノードが中央の男性、ハイジャック、消極的盗聴、ものまねに被害を受け易い。
Arkko, et al. Standards Track [Page 3] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[3ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
denial-of-service attacks. Any third parties are also vulnerable to denial-of-service attacks, for instance if an attacker could direct the traffic flowing through the home agent to a innocent third party. These attacks are discussed in more detail in Section 15.1 of the Mobile IPv6 base specification [7].
サービス不能攻撃。 また、どんな第三者もサービス不能攻撃に被害を受け易いです、例えば、攻撃者がそうすることができるなら、潔白な第三者のホームのエージェントを通して流れるトラフィックを向けてください。 さらに詳細にモバイルIPv6基礎仕様[7]のセクション15.1でこれらの攻撃について議論します。
In order to avoid these attacks, the base specification uses IPsec Encapsulating Security Payload (ESP) [3] to protect control traffic between the home agent and the mobile node. This control traffic consists of various messages carried by the Mobility Header protocol in IPv6 [5]. The traffic takes the following forms:
これらの攻撃を避けて、基礎仕様は、ホームのエージェントとモバイルノードの間のコントロールトラフィックを保護するのにIPsec Encapsulating Security有効搭載量(超能力)[3]を使用します。 このコントロールトラフィックはIPv6[5]でMobility Headerプロトコルによって伝えられる様々なメッセージから成ります。 トラフィックは以下の形を取ります:
o Binding Update and Acknowledgement messages exchanged between the
mobile node and the home agent, as described in Sections 10.3.1,
10.3.2, 11.7.1, and 11.7.3 of the base specification [7].
o セクション10.3.1、10.3で.2、11.7について説明するとき拘束力があるUpdateとAcknowledgementメッセージがモバイルノードとホームのエージェントの間で交換した、.1、11.7は.3の基礎仕様[7]をそうします。
o Return routability messages Home Test Init and Home Test that pass
through the home agent on their way to a correspondent node, as
described in Section 10.4.6 of the base specification [7].
o 通信員ノードへの途中にホームのエージェントを通り抜けるroutabilityメッセージのホームTest InitとホームTestを返してください、.6のセクション10.4基礎仕様[7]で説明されるように。
o ICMPv6 messages exchanged between the mobile node and the home
agent for the purposes of prefix discovery, as described in
Sections 10.6 and 11.4 of the base specification [7].
o 基礎仕様[7]のセクション10.6と11.4で説明されるようにモバイルノードとホームのエージェントの間で接頭語発見の目的と交換されたICMPv6メッセージ。
The nodes may also optionally protect payload traffic passing through the home agent, as described in Section 5.5 of the base specification [7]. If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection support is required.
また、ノードは任意にホームのエージェントを通り抜けるペイロードトラフィックを保護するかもしれません、基礎仕様[7]のセクション5.5で説明されるように。 マルチキャストグループ会員資格制御プロトコルかstatefulアドレス自動構成プロトコルがサポートされるなら、ペイロードデータ保護サポートが必要です。
The control traffic between the mobile node and the home agent requires message authentication, integrity, correct ordering and anti-replay protection. The mobile node and the home agent must have an IPsec security association to protect this traffic. IPsec does not proving correct ordering of messages. Correct ordering of the control traffic is ensured by a sequence number in the Binding Update and Binding Acknowledgement messages. The sequence number in the Binding Updates also provides protection to a certain extent. It fails in some scenarios, for example, if the Home Agent loses the Binding Cache state. Full protection against replay attacks is possible only when IKE is used.
モバイルノードとホームのエージェントの間のコントロールトラフィックは通報認証、保全、正しい注文、および反反復操作による保護を必要とします。 モバイルノードとホームのエージェントには、このトラフィックを保護するIPsecセキュリティ協会がなければなりません。 メッセージを注文しながら正しいと判明して、IPsecはそうしません。 Binding UpdateとBinding Acknowledgementメッセージの一連番号でコントロールトラフィックの正しい注文を確実にします。 また、Binding Updatesの一連番号はある程度保護を提供します。 例えば、ホームのエージェントがBinding Cache状態を失うなら、それはいくつかのシナリオに失敗します。 IKEが使用されているときだけ、反射攻撃に対する完全な保護は可能です。
Great care is needed when using IKE [4] to establish security associations to Mobile IPv6 home agents. The right kind of addresses must be used for transporting IKE. This is necessary to avoid circular dependencies in which the use of a Binding Update triggers the need for an IKE exchange that cannot complete prior to the Binding Update having been completed.
モバイルIPv6ホームのエージェントにセキュリティ協会を証明するのにIKE[4]を使用するとき、高度の注意が必要です。 IKEを輸送するのにアドレスの正しい種類を使用しなければなりません。 これが、Binding Updateの使用がそれが完成したBinding Updateの前で終了できないIKE交換の必要性の引き金となる円形の依存を避けるのに必要です。
Arkko, et al. Standards Track [Page 4] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[4ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
The mobile IPv6 base document defines the main requirements the mobile nodes and home agents must follow when securing the above traffic. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
モバイルIPv6元にした文書は上のトラフィックを保証するときモバイルノードとホームのエージェントが後をつけなければならない主な要件を定義します。 このドキュメントは、正しい注文により多くの深さでこれらの要件について議論して、中古のパケット・フォーマットを例証して、適当な構成手順を説明して、実装がどうパケットを処理できるかを示しています。
We begin our description by showing the required wire formats for the protected packets in Section 3. Section 4 describes rules which associated Mobile IPv6, IPsec, and IKE implementations must observe. Section 5 discusses how to configure either manually keyed IPsec security associations or how to configure IKE to establish them automatically. Section 6 shows examples of how packets are processed within the nodes.
私たちは、セクション3に保護されたパケットのための必要なワイヤ書式を示していることによって、記述を始めます。 セクション4は関連モバイルIPv6、IPsec、およびIKE実装が守らなければならない規則について説明します。 セクション5は手動で合わせられたIPsecセキュリティ協会かIKEを自動的にそれらを証明するためにどう構成のどちらかであるかを構成する方法を論じます。 セクション6はパケットがノードの中でどう処理されるかに関する例を示しています。
All implementations of Mobile IPv6 mobile node and home agent MUST support at least the formats described in Section 3 and obey the rules in Section 4.
モバイルIPv6モバイルノードとホームのエージェントのすべての実装が、少なくともセクション3で説明された形式をサポートして、セクション4で規則を守らなければなりません。
The configuration and processing sections are informative, and should only be considered as one possible way of providing the required functionality.
構成と処理部は、有益であり、必要な機能性を提供する1つの可能な方法であるとみなされるだけであるべきです。
Note that where this document indicates a feature MUST be supported and SHOULD be used, this implies that all implementations must be capable of using the specified feature, but there may be cases where, for instance, a configuration option disables to use of the feature in a particular situation.
例えば、このドキュメントが、特徴をサポートしなければならないのを示して、SHOULDが使用されて、これがすべての実装が指定された特徴を使用できなければなりませんが、ケースがどこであったかでそこでは、使用するかもしれないのを含意するそんなにところで設定オプションが特定の状況における特徴の使用に無効にすることに注意してください。
2. Terminology
2. 用語
The keywords "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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
3. Packet Formats
3. パケット・フォーマット
3.1. Binding Updates and Acknowledgements
3.1. 拘束力があるアップデートと承認
When the mobile node is away from its home, the BUs sent by it to the home agent MUST support at least the following headers in the following order:
モバイルノードが家にいないときに、それによってホームのエージェントに送られたBUsは以下のオーダーで少なくとも以下のヘッダーを支えなければなりません:
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header in transport mode
IPv6ヘッダー、(ソース=、注意、-、アドレス、目的地=ホームエージェント) 交通機関による目的地OptionsヘッダーホームAddressオプション(ホームアドレス)超能力ヘッダー
Arkko, et al. Standards Track [Page 5] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[5ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Mobility header
Binding Update
Alternate Care-of Address option (care-of address)
移動性ヘッダー、Binding Update Alternate Care、-、Addressオプション(注意、-、アドレス)
Note that the Alternate Care-of Address option is used to ensure that the care-of address is protected by ESP. The home agent considers the address within this option as the current care-of address for the mobile node. The home address is not protected by ESP directly, but the use of a specific home address with a specific security association is required by policy.
それに注意してください、Alternate Care、-、Addressオプションがそれを確実にするのに使用される、注意、-、アドレス、超能力で、保護されます。 ホームのエージェントが、このオプションの中のアドレスが電流であるとみなす、注意、-、モバイルノードのためのアドレス。 ホームアドレスは超能力によって直接保護されませんが、特定のセキュリティ関係との特定のホームアドレスの使用は方針によって必要とされます。
The Binding Acknowledgements sent back to the mobile node when it is away from home MUST support at least the following headers in the following order:
それが家にいないときにモバイルノードが送り返されたBinding Acknowledgementsは以下のオーダーで少なくとも以下のヘッダーを支えなければなりません:
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header in transport mode
Mobility header
Binding Acknowledgement
IPv6ヘッダー、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、交通機関MobilityヘッダーBinding Acknowledgementというルート設定ヘッダー(2をタイプする)ホームアドレス超能力ヘッダー
When the mobile node is at home, the above rules are different as the mobile node can use its home address as a source address. This typically happens for the de-registration Binding Update when the mobile is returning home. In this situation, the Binding Updates MUST support at least the following headers in the following order:
モバイルノードがホームにあるとき、モバイルノードがソースアドレスとしてホームアドレスを使用できるので、上の規則は異なっています。 モバイルが家に帰っているとき、これは反-登録Binding Updateのために通常起こります。 この状況で、Binding Updatesは以下のオーダーで少なくとも以下のヘッダーを支えなければなりません:
IPv6 header (source = home address,
destination = home agent)
ESP header in transport mode
Mobility header
Binding Update
交通機関MobilityヘッダーBinding UpdateというIPv6ヘッダー(目的地=ホームエージェント、ソースはホームアドレスと等しい)超能力ヘッダー
The Binding Acknowledgement messages sent to the home address MUST support at least the following headers in the following order:
ホームアドレスに送られたBinding Acknowledgementメッセージは以下のオーダーで少なくとも以下のヘッダーを支えなければなりません:
IPv6 header (source = home agent,
destination = home address)
ESP header in transport mode
Mobility header
Binding Acknowledgement
交通機関MobilityヘッダーBinding AcknowledgementというIPv6ヘッダー(ソース=ホームエージェント、目的地=ホームアドレス)超能力ヘッダー
Arkko, et al. Standards Track [Page 6] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[6ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
3.2. Return Routability Signaling
3.2. リターンRoutabilityシグナリング
When the Home Test Init messages tunneled to the home agent are protected by IPsec, they MUST support at least the following headers in the following order:
ホームのエージェントにトンネルを堀られたホームTest InitメッセージがIPsecによって保護されるとき、以下のオーダーで少なくとも以下のヘッダーを支えなければなりません:
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test Init
IPv6ヘッダー、(ソース=、注意、-、アドレス、目的地=ホームエージェント) トンネルモードIPv6ヘッダー(ソースはホームアドレスと等しいです、目的地=通信員ノード)移動性HeaderホームTest Initの超能力ヘッダー
This format assumes that the mobile node's current care-of address is used as the outer header destination address in the security association. As discussed in Section 4.3, this requires the home agent to update the destination address when the mobile node moves. Policy entries and security association selectors stay the same, however, as the inner packets do not change upon movements.
この形式が、モバイルノードがよく見られると仮定する、注意、-、アドレスは外側のヘッダー送付先アドレスとしてセキュリティ協会で使用されます。 セクション4.3で議論するように、モバイルノードが移行すると、これは、ホームのエージェントが送付先アドレスをアップデートするのを必要とします。 しかしながら、内側のパケットが動きのときに変化しないのに従って、方針エントリーとセキュリティ協会セレクタは同じままです。
Note that there are trade-offs in using care-of addresses as the destination addresses versus using the home address and attaching an additional Home Address destination option and/or Routing header to the packets. The basis for requiring support for at least the care-of address case has been discussed in Section 7.
使用中であるトレードオフがあることに注意してください、注意、-、ホームアドレスと付くことを使用することに対して目的地がパケットへの追加ホームAddress目的地オプション、そして/または、ルート設定ヘッダーに演説するとき、扱います。 支持を要する基礎、少なくとも、注意、-、セクション7でアドレスケースについて議論しました。
Similarly, when the Home Test messages tunneled from the home agent are protected by IPsec, they MUST support at least the following headers in the following order:
ホームのエージェントからトンネルを堀られたホームTestメッセージがIPsecによって保護されるとき、同様に、以下のオーダーで少なくとも以下のヘッダーを支えなければなりません:
IPv6 header (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test
IPv6ヘッダー、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、トンネルモードIPv6ヘッダー(ソースは通信員ノードと等しいです、目的地=ホームアドレス)移動性HeaderホームTestの超能力ヘッダー
The format used to protect return routability packets relies on the destination of the tunnel packets to change for the mobile node as it moves. The home agent's address stays the same, but the mobile node's address changes upon movements, as if the security association's outer header destination address had changed. When the mobile node adopts a new care-of address, it adopts also a new source address for outgoing tunnel packets. The home agent accepts packets sent like this, as the outer source address in tunnel packets is not checked according to the rules in RFC 2401. (We note, however, that
リターンroutabilityパケットを保護するのに使用される形式は、移行するときモバイルノードのために変化するようにトンネルパケットの目的地を当てにします。 ホームのエージェントのアドレスは同じ状態で残っていますが、モバイルノードのアドレスは動きのときに変化します、まるでセキュリティ協会の外側のヘッダー送付先アドレスが変化したかのように。 モバイルノードが新しい状態でaを採用する、注意、-、アドレス、また、それは出発しているトンネルパケットのための新しいソースアドレスを採用します。 ホームのエージェントはこのように送られたパケットを受け入れます、RFC2401の規則に従ってトンネルパケットの外側のソースアドレスがチェックされないとき。 (しかしながら、私たちはそれに注意します。
Arkko, et al. Standards Track [Page 7] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[7ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
some implementations are known to make source address checks.) For a discussion of the role of source addresses in outer tunnel headers, see Section 5.1.2.1 of RFC 2401 [2]. Note also that the home agent requires the packets to be authenticated regardless of the source address change, hence the "new" sender must possess the same keys for the security association as it had in the previous location. This proves that the sender is the same entity, regardless of the changes in the addresses.
いくつかの実装がソースアドレスをチェックにするのが知られています。) 外トンネルヘッダーでのソースアドレスの役割の議論に関して、セクション5.1を見てください。.2 .1RFC2401[2]。 また、ホームのエージェントが、パケットがソースアドレス変化にかかわらず認証されるのを必要とするというメモ、したがって、「新しい」送付者は所有していたように前の位置でセキュリティ協会のための同じキーを所有しなければなりません。 これは、アドレスにおける変化にかかわらず送付者が同じ実体であると立証します。
The process is more complicated in the home agent side, as the home agent has stored the previous care-of address in its Security Association Database as the outer header destination address. When IKE is being used, the mobile node runs it on top of its current care-of address, and the resulting tunnel-mode security associations will use the same addresses as IKE run over. In order for the home agent to be able to tunnel a Home Test message to the mobile node, it uses the current care-of address as the destination of the tunnel packets, as if the home agent had modified the outer header destination address in the security association used for this protection. This implies that the same security association can be used in multiple locations, and no new configuration or re-establishment of IKE phases is needed per movement. Section 5.2.2 discusses the security policy and security association database entries that are needed to accomplish this.
ホームのエージェント側では、プロセスが、より複雑です、ホームのエージェントが前を保存したとき注意、-、Security Association Databaseの外側のヘッダー送付先アドレスとしてのアドレス。 上、IKEが使用されているとき、モバイルノードがそれを実行する、電流、注意、-、アドレス、IKEとしてのセキュリティ協会が同じように使用するトンネルモードアドレスが. ホームのエージェントのホームTestメッセージにモバイルノードにトンネルを堀ることができます、電流を使用するということであるIn命令の上で実行する結果になる、注意、-、トンネルパケットの目的地として、まるでホームのエージェントがこの保護に使用されるセキュリティ協会で外側のヘッダー送付先アドレスを変更したかのように、扱います。 これは、複数の位置にもかかわらず、どんな新しい構成にも同じセキュリティ協会を使用できないか、またはIKEフェーズの再建が動き単位で必要であることを含意します。 セクション5.2 .2 これを達成するのに必要である安全保障政策とセキュリティ協会データベースエントリーについて議論します。
3.3. Prefix Discovery
3.3. 接頭語発見
If IPsec is used to protect prefix discovery, requests for prefixes from the mobile node to the home agent MUST support at least the following headers in the following order.
IPsecが接頭語発見を保護するのに使用されるなら、モバイルノードからホームのエージェントまでの接頭語を求める要求は以下のオーダーで少なくとも以下のヘッダーを支えなければなりません。
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header in transport mode
ICMPv6
Mobile Prefix Solicitation
IPv6ヘッダー、(ソース=、注意、-、アドレス、目的地=ホームエージェント) 交通機関のICMPv6のモバイルPrefix Solicitationによる目的地OptionsヘッダーホームAddressオプション(ホームアドレス)超能力ヘッダー
Again if IPsec is used, solicited and unsolicited prefix information advertisements from the home agent to the mobile node MUST support at least the following headers in the following order.
一方、IPsecが使用されているなら、ホームのエージェントからモバイルノードまでの請求されて求められていない接頭語情報広告は以下のオーダーで少なくとも以下のヘッダーを支えなければなりません。
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header in transport mode
IPv6ヘッダー、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、交通機関によるルート設定ヘッダー(2をタイプする)ホームアドレス超能力ヘッダー
Arkko, et al. Standards Track [Page 8] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[8ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
ICMPv6
Mobile Prefix Advertisement
ICMPv6のモバイル接頭語広告
3.4. Payload Packets
3.4. 有効搭載量パケット
If IPsec is used to protect payload packets tunneled to the home agent from the mobile node, we use a format similar to the one in Section 3.2. However, instead of the MobilityHeader, these packets may contain any legal IPv6 protocol(s):
IPsecがモバイルノードからホームのエージェントにトンネルを堀られたペイロードパケットを保護するのに使用されるなら、私たちはセクション3.2におけるものと同様の形式を使用します。 しかしながら、MobilityHeaderの代わりに、これらのパケットはどんな法的なIPv6プロトコルも含むかもしれません:
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Any protocol
IPv6ヘッダー、(ソース=、注意、-、アドレス、目的地=ホームエージェント) いずれも議定書の中で述べるトンネルモードIPv6ヘッダー(ソースはホームアドレスと等しいです、目的地=通信員ノード)という超能力ヘッダー
Similarly, when the payload packets are tunneled from the home agent to the mobile node with ESP encapsulation, they MUST support at least the following headers in the following order:
ペイロードパケットが超能力カプセル化でホームのエージェントからモバイルノードまでトンネルを堀られるとき、同様に、以下のオーダーで少なくとも以下のヘッダーを支えなければなりません:
IPv6 header (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent node,
destination = home address)
Any protocol
IPv6ヘッダー、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、いずれも議定書の中で述べるトンネルモードIPv6ヘッダー(ソースは通信員ノードと等しいです、目的地=ホームアドレス)という超能力ヘッダー
4. Requirements
4. 要件
This section describes mandatory rules for all Mobile IPv6 mobile nodes and home agents. These rules are necessary in order for it to be possible to enable IPsec communications despite movements, guarantee sufficient security, and to ensure correct processing order of packets.
このセクションはすべてのモバイルIPv6モバイルノードとホームのエージェントのために委任統治を説明します。 これらの規則が、それが動き、保証の十分なセキュリティにもかかわらず、IPsecコミュニケーションを可能にして、パケットの正しい処理命令を確実にするのにおいて可能であるのに必要です。
The rules in the following sections apply only to the communications between home agents and mobile nodes. They should not be taken as requirements on how IPsec in general is used by mobile nodes.
以下のセクションの規則はホームのエージェントとモバイルノードとのコミュニケーションだけに適用されます。 一般に、IPsecがモバイルノードによってどう使用されるかに関する要件としてそれらをみなすべきではありません。
Arkko, et al. Standards Track [Page 9] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[9ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
4.1. Mandatory Support
4.1. 義務的なサポート
The following requirements apply to both home agents and mobile nodes:
以下の要件はホームのエージェントとモバイルノードの両方に適用されます:
o Manual configuration of IPsec security associations MUST be
supported. The configuration of the keys is expected to take
place out-of-band, for instance at the time the mobile node is
configured to use its home agent.
o IPsecセキュリティ協会の手動の構成をサポートしなければなりません。 キーの構成がバンドの外で行われると予想されて、例えば、当時、モバイルノードは、ホームのエージェントを使用するために構成されます。
o Automatic key management with IKE [4] MAY be supported. Only
IKEv1 is discussed in this document. Other automatic key
management mechanisms exist and will appear beyond IKEv1, but this
document does not address the issues related to them.
o IKE[4]との自動かぎ管理はサポートされるかもしれません。 本書ではIKEv1だけについて議論します。 他の自動かぎ管理メカニズムは、存在していて、IKEv1を超えて現れるでしょうが、このドキュメントはそれらに関連する問題を扱いません。
o ESP encapsulation of Binding Updates and Acknowledgements between
the mobile node and home agent MUST be supported and MUST be used.
o モバイルノードとホームのエージェントの間のBinding UpdatesとAcknowledgementsの超能力カプセル化をサポートしなければならなくて、使用しなければなりません。
o ESP encapsulation of the Home Test Init and Home Test messages
tunneled between the mobile node and home agent MUST be supported
and SHOULD be used.
o ホームTest InitとホームTestメッセージの超能力カプセル化はモバイルノードと、エージェントをサポートしなければならないホームとSHOULDの間でトンネルを堀りました。使用されます。
o ESP encapsulation of the ICMPv6 messages related to prefix
discovery MUST be supported and SHOULD be used.
o ICMPv6メッセージの超能力カプセル化は発見をサポートしなければならない接頭語とSHOULDに関連しました。使用されます。
o ESP encapsulation of the payload packets tunneled between the
mobile node and home agent MAY be supported and used.
o モバイルノードとホームのエージェントの間でトンネルを堀られたペイロードパケットの超能力カプセル化は、サポートされて、使用されるかもしれません。
o If multicast group membership control protocols or stateful
address autoconfiguration protocols are supported, payload data
protection MUST be supported for those protocols.
o マルチキャストグループ会員資格制御プロトコルかstatefulアドレス自動構成プロトコルがサポートされるなら、それらのプロトコルのためにペイロードデータ保護をサポートしなければなりません。
4.2. Policy Requirements
4.2. 方針要件
The following requirements apply to both home agents and mobile nodes:
以下の要件はホームのエージェントとモバイルノードの両方に適用されます:
o As required in the base specification [7], when a packet destined
to the receiving node is matched against IPsec security policy or
selectors of a security association, an address appearing in a
Home Address destination option is considered as the source
address of the packet.
o 受信ノードに運命づけられたパケットがセキュリティ協会のIPsec安全保障政策かセレクタに取り組まされるとき、必要に応じて、基礎仕様[7]では、ホームAddress目的地オプションに現れるアドレスはパケットのソースアドレスであるとみなされます。
Note that the home address option appears before IPsec headers.
Section 11.3.2 of the base specification describes one possible
implementation approach for this: The IPsec policy operations can
be performed at the time when the packet has not yet been modified
per Mobile IPv6 rules, or has been brought back to its normal form
ホームアドレスオプションがIPsecヘッダーの前に現れることに注意してください。 .2のセクション11.3基礎仕様がこれのための1つの可能な実装アプローチについて説明します: パケットがモバイルIPv6規則単位でまだ変更されていないか、または正規形に返されたとき、IPsec政策運営を実行できます。
Arkko, et al. Standards Track [Page 10] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[10ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
after Mobile IPv6 processing. That is, the processing of the Home
Address option is seen as a fixed transformation of the packets
that does not affect IPsec processing.
モバイルIPv6処理の後に。 すなわち、ホームAddressオプションの処理はIPsec処理に影響しないパケットの固定変換と考えられます。
o Similarly, a home address within a Type 2 Routing header destined
to the receiving node is considered as the destination address of
the packet, when a packet is matched against IPsec security policy
or selectors of a security association.
o 同様に、受信ノードを運命づけられたType2ルート設定ヘッダーの中のホームアドレスはパケットの送付先アドレスであるとみなされます、パケットがセキュリティ協会のIPsec安全保障政策かセレクタに取り組まされるとき。
Similar implementation considers apply to the Routing header
processing as was described above for the Home Address destination
option.
同様の実装は、ホームAddress目的地オプションのために上で説明されたルート設定ヘッダー処理に適用するように考えます。
o When IPsec is used to protect return routability signaling or
payload packets, this protection MUST only be applied to the
return routability packets entering the IPv6 encapsulated tunnel
interface between the mobile node and the home agent. This can be
achieved, for instance, by defining the security policy database
entries specifically for the tunnel interface. That is, the
policy entries are not generally applied on all traffic on the
physical interface(s) of the nodes, but rather only on traffic
that enters this tunnel.
o IPsecがリターンroutabilityシグナリングかペイロードパケットを保護するのに使用されるとき、モバイルノードとホームのエージェントとのトンネルのインタフェースであるとカプセル化されたIPv6に入りながら、リターンroutabilityパケットにこの保護を適用するだけでよいです。 例えば、特にトンネルのインタフェースのための安全保障政策データベースエントリーを定義することによって、これを達成できます。 一般に、すなわち、方針エントリーはノードの物理インターフェースにもかかわらず、むしろこのトンネルに入るトラフィックだけに関するすべてのトラフィックで適用されません。
o The authentication of mobile nodes MAY be based either on machine
or user credentials. Note that multi-user operating systems
typically allow all users of a node to use any of the IP addresses
assigned to the node. This limits the capability of the home
agent to restrict the use of a home address to a particular user
in such environment. Where user credentials are applied in a
multi-user environment, the configuration should authorize all
users of the node to control all home addresses assigned to the
node.
o モバイルノードの認証はマシンかユーザ資格証明書に基づくかもしれません。 ノードのすべてのユーザがマルチユーザオペレーティングシステムでノードに割り当てられたIPアドレスのどれかを通常使用できることに注意してください。 これはホームのエージェントがそのような環境でホームアドレスの使用を特定のユーザに制限する能力を制限します。 ユーザ資格証明書がマルチユーザ環境で適用されるところでは、構成は、ノードのすべてのユーザがノードに割り当てられたすべてのホームアドレスを制御するのを認可するべきです。
o When the mobile node returns home and de-registers with the Home
Agent, the tunnel between the home agent and the mobile node's
care-of address is torn down. The security policy entries, which
were used for protecting tunneled traffic between the mobile node
and the home agent MUST be made inactive (for instance, by
removing them and installing them back later through an API). The
corresponding security associations could be kept as they are or
deleted depending on how they were created. If the security
associations were created dynamically using IKE, they are
automatically deleted when they expire. If the security
associations were created through manual configuration, they MUST
be retained and used later when the mobile node moves away from
home again. The security associations protecting Binding Updates
and Acknowledgements, and prefix discovery SHOULD NOT be deleted
as they do not depend on care-of addresses and can be used again.
o When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down. 安全保障政策エントリー。(そのエントリーは保護するのに使用されて、モバイルノードとホームのエージェントの間のトンネルを堀られたトラフィックを不活発に(例えばAPIを通してそれらを取り外して、後でそれらをインストールして戻すことによって)しなければならないということでした)。 それらがどう作成されたかによって、対応するセキュリティ協会をそれらが維持されたように維持したか、または削除できました。 期限が切れるとき、セキュリティ協会がダイナミックにIKEを使用することで創設されたなら、それらは自動的に削除されます。 セキュリティ協会が手動の構成を通して創設されたなら、モバイルノードが後で再びホームから遠くに移行するとき、それらを保有されて、使用しなければなりません。 そして、Binding Updates、Acknowledgements、および接頭語発見SHOULD NOTを保護するセキュリティ協会、彼らがよらないで削除されてください、オンである、注意、-、アドレス、再び使用できます。
Arkko, et al. Standards Track [Page 11] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[11ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
The following rules apply to mobile nodes:
以下の規則はモバイルノードに適用されます:
o The mobile node MUST use the Home Address destination option in
Binding Updates and Mobile Prefix Solicitations, sent to the home
agent from a care-of address.
o モバイルノードがホームのエージェントに送られたBinding UpdatesとモバイルPrefix SolicitationsのホームAddress目的地オプションを使用しなければならない、注意、-、アドレス
o When the mobile node receives a changed set of prefixes from the
home agent during prefix discovery, there is a need to configure
new security policy entries, and there may be a need to configure
new security associations. It is outside the scope of this
specification to discuss automatic methods for this.
o モバイルノードが接頭語発見の間ホームのエージェントから変えられたセットの接頭語を受け取るとき、新しい安全保障政策エントリーを構成する必要があります、そして、新しいセキュリティ協会を構成する必要があるかもしれません。 これのために自動メソッドについて議論するために、この仕様の範囲の外にそれはあります。
The following rules apply to home agents:
以下の規則はホームのエージェントに適用されます:
o The home agent MUST use the Type 2 Routing header in Binding
Acknowledgements and Mobile Prefix Advertisements sent to the
mobile node, again due to the need to have the home address
visible when the policy checks are made.
o ホームのエージェントはモバイルノードに送られたBinding AcknowledgementsとモバイルPrefix AdvertisementsでType2ルート設定ヘッダーを使用しなければなりません、方針チェックをするとき目に見えるホームアドレスを持つ再び必要性のため。
o It is necessary to avoid the possibility that a mobile node could
use its security association to send a Binding Update on behalf of
another mobile node using the same home agent. In order to do
this, the security policy database entries MUST unequivocally
identify a single security association for protecting Binding
Updates between any given home address and home agent when
manually keyed IPsec security associations are used. When dynamic
keying is used, the security policy database entries MUST
unequivocally identify the IKE phase 1 credentials which can be
used to authorize the creation of security associations for
protecting Binding Updates for a particular home address. How
these mappings are maintained is outside the scope of this
specification, but they may be maintained, for instance, as a
locally administered table in the home agent. If the phase 1
identity is a Fully Qualified Domain Name (FQDN), secure forms of
DNS may also be used.
o モバイルノードが同じホームのエージェントを使用することで別のモバイルノードを代表してBinding Updateを送るセキュリティ協会を使用するかもしれない可能性を避けるのが必要です。 これをして、安全保障政策データベースエントリーは、手動で合わせられたIPsecセキュリティ協会が使用されているときどんな与えられたホームアドレスとホームのエージェントの間のBinding Updatesを保護するために明確に単一のセキュリティ協会を特定しなければなりません。 ダイナミックな合わせるのが使用されているとき、安全保障政策データベースエントリーは明確に、特定のホームアドレスのためにBinding Updatesを保護するためにセキュリティ協会の創設を認可するのに使用できるIKEフェーズ1資格証明書を特定しなければなりません。 この仕様の範囲の外にこれらのマッピングがどう維持されるかがありますが、例えば、それらは局所的に管理されたテーブルとしてホームのエージェントで維持されるかもしれません。 また、フェーズ1のアイデンティティがFully Qualified Domain Name(FQDN)であるなら、DNSの安全なフォームは使用されるかもしれません。
o When the set of prefixes advertised by the home agent changes,
there is a need to configure new security policy entries, and
there may be a need to configure new security associations. It is
outside the scope of this specification to discuss automatic
methods for this, if new home addresses are required.
o 接頭語のセットがホームエージェント変化で広告を出したとき、新しい安全保障政策エントリーを構成する必要があります、そして、新しいセキュリティ協会を構成する必要があるかもしれません。 新しいホームアドレスが必要であるなら、これのために自動メソッドについて議論するために、この仕様の範囲の外にそれはあります。
Arkko, et al. Standards Track [Page 12] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[12ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
4.3. IPsec Protocol Processing
4.3. IPsecプロトコル処理
The following requirements apply to both home agents and mobile nodes:
以下の要件はホームのエージェントとモバイルノードの両方に適用されます:
o When securing Binding Updates, Binding Acknowledgements, and
prefix discovery, both the mobile nodes and the home agents MUST
support and SHOULD use the Encapsulating Security Payload (ESP)
[3] header in transport mode and MUST use a non-null payload
authentication algorithm to provide data origin authentication,
connectionless integrity and optional anti-replay protection.
o Binding Updatesを固定するとき、Binding Acknowledgements、接頭語発見、モバイルノードとホームのエージェントが支えなければならない両方、およびSHOULDは、交通機関でEncapsulating Security有効搭載量(超能力)[3]ヘッダーを使用して、データ発生源認証、コネクションレスな保全、および任意の反反復操作による保護を提供するのに非ヌルペイロード認証アルゴリズムを使用しなければなりません。
Mandatory support for encryption and integrity protection
algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC
2406 [3]. Care is needed when selecting suitable encryption
algorithms for ESP, however. Currently available integrity
protection algorithms are in general considered to be secure. The
encryption algorithm, DES, mandated by the current IPsec standards
is not, however. This is particularly problematic when IPsec
security associations are configured manually, as the same key is
used for a long time.
暗号化と保全保護アルゴリズムの義務的なサポートがRFC2401[2]、RFC2402[8]、およびRFC2406[3]で定義されるようにあります。 しかしながら、超能力のために適当な暗号化アルゴリズムを選択するとき、注意が必要です。一般に、現在利用可能な保全保護アルゴリズムが安全であると考えられます。 暗号化アルゴリズム、しかしながら、現在のIPsec規格によって強制されたDESはそうでなく、IPsecセキュリティ協会が手動で構成されるとき. これは特に問題が多いです、同じキーが長い間使用されるとき。
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the
protection of packets belonging to the return routability
procedure. A non-null encryption transform and a non-null
authentication algorithm MUST be applied.
o 超能力をサポートしなければならないモードIPsecとSHOULDにトンネルを堀ってください。パケットの保護には、リターンroutability手順に属しながら、使用されてください。 非ヌルの暗号化変換と非ヌルの認証アルゴリズムを適用しなければなりません。
Note that the return routability procedure involves two message
exchanges from the mobile node to the correspondent node. The
purpose of these exchanges is to assure that the mobile node is
live at the claimed home and care-of addresses. One of the
exchanges is sent directly to and from the correspondent node,
while another one is tunneled through the home agent. If an
attacker is on the mobile node's link and the mobile node's
current link is an unprotected wireless link, the attacker would
able to see both sets of messages, and launch attacks based on it
(these attacks are discussed further in Section 15.4 of the base
specification [7].) One can prevent the attack by making sure
that the packets tunneled through the home agent are encrypted.
リターンroutability手順がモバイルノードから通信員ノードまで2つの交換処理にかかわることに注意してください。 そして、これらの交換の目的がモバイルノードが要求されたホームでライブであることを保証することである、注意、-、アドレス。 直接ノードと通信員ノードから交換の1つを送ります、別の1つはホームのエージェントを通してトンネルを堀られますが。 攻撃者がモバイルノードのリンクとモバイルノードの現在のリンクの上にいるなら、リンク、攻撃者がそうする保護のないワイヤレスは、メッセージのセットと着手攻撃の両方がそれに基づいているのを見ることができますか?(基礎仕様[7]のセクション15.4で、より詳しくこれらの攻撃について議論します。) ホームのエージェントを通してトンネルを堀られたパケットが暗号化されているのを確実にすることによって、1つは攻撃を防ぐことができます。
Note that this specification concerns itself only with on-the-wire
formats, and does not dictate specific implementations mechanisms.
In the case of IPsec tunnel mode, the use of IP-in-IP
encapsulation followed by IPsec transport mode encapsulation may
also be possible.
この仕様がワイヤの上に形式しかなくタッチしていて、特定の実装メカニズムを決めないことに注意してください。また、IPsecトンネルモードの場合では、IPsec交通機関カプセル化があとに続いたIPにおけるIPカプセル化の使用も可能であってもよいです。
Arkko, et al. Standards Track [Page 13] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[13ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
The following rules apply to mobile nodes:
以下の規則はモバイルノードに適用されます:
o When ESP is used to protect Binding Updates, there is no
protection for the care-of address which appears in the IPv6
header outside the area protected by ESP. It is important for the
home agent to verify that the care-of address has not been
tampered with. As a result, the attacker would have redirected
the mobile node's traffic to another address. In order to prevent
this, Mobile IPv6 implementations MUST use the Alternate Care-of
Address mobility option in Binding Updates sent by mobile nodes
while away from home. The exception to this is when the mobile
node returns home and sends a Binding Update to the home agent in
order to de-register. In this case no Alternate Care-of Address
option is needed, as described in Section 3.1.
o いつの間、超能力がBinding Updatesを保護するのに使用されて、ノー・プロテクションがあるか、注意、-、領域の外のIPv6ヘッダーに現れるアドレスは超能力によって保護されました。 ホームのエージェントがそれについて確かめるのが、重要である、注意、-、アドレス、いじられていません。 その結果、攻撃者はモバイルノードのトラフィックを別のアドレスに向け直したでしょう。 モバイルIPv6実装がこれを防ぐのに使用されなければならない、Alternate Care、-、ホームから離れていますが、モバイルノードによって送られたBinding UpdatesのAddress移動性オプション。 これへの例外はモバイルノードが反-登録するためにホームのエージェントに家に帰って、Binding Updateを送る時です。 いいえ、この場合、Alternate Care、-、Addressオプションがセクション3.1で説明されるように必要です。
When IPsec is used to protect return routability signaling or
payload packets, the mobile node MUST set the source address it
uses for the outgoing tunnel packets to the current primary care-
of address. The mobile node starts to use a new primary care-of
address immediately after sending a Binding Update to the home
agent to register this new address. Similarly, it starts to use
the new address as the required destination address of tunneled
packets received from the home agent.
IPsecがリターンroutabilityシグナリングかペイロードパケットを保護するのに使用されるとき、モバイルノードはそれが出発しているトンネルパケットにアドレスの電流初期医療に使用するソースアドレスを設定しなければなりません。 モバイルノードが新しい状態でaを使用し始める、初期医療、-、登録するホームのエージェントへのBinding Updateを送る直後、この新しいアドレスを扱ってください。 同様に、トンネルを堀られたパケットの必要な送付先アドレスがホームのエージェントから受信されたので、それは新しいアドレスを使用し始めます。
The following rules apply to home agents:
以下の規則はホームのエージェントに適用されます:
o When IPsec is used to protect return routability signaling or
payload packets, IPsec security associations are needed to provide
this protection. When the care-of address for the mobile node
changes as a result of an accepted Binding Update, special
treatment is needed for the next packets sent using these security
associations. The home agent MUST set the new care-of address as
the destination address of these packets, as if the outer header
destination address in the security association had changed.
Similarly, the home agent starts to expect the new source address
in the tunnel packets received from the mobile node.
o IPsecがリターンroutabilityシグナリングかペイロードパケットを保護するのに使用されるとき、IPsecセキュリティ協会がこの保護を提供するのが必要です。 いつ、注意、-、モバイルノードのためのアドレスは受け入れられたBinding Updateの結果、変化して、特別な処理がこれらのセキュリティ協会が使用させられた次のパケットに必要であるか。 ホームのエージェントが新しさを設定しなければならない、注意、-、これらのパケットの送付先アドレスとして、まるでセキュリティ協会における外側のヘッダー送付先アドレスが変化したかのように、扱います。 同様に、ホームのエージェントはモバイルノードから受け取られたトンネルパケットで新しいソースアドレスを予想し始めます。
Such address changes can be implemented, for instance, through an
API from the Mobile IPv6 implementation to the IPsec
implementation. It should be noted that the use of such an API
and the address changes MUST only be done based on the Binding
Updates received by the home agent and protected by the use of
IPsec. Address modifications based on other sources, such as
Binding Updates to the correspondent nodes protected by return
routability, or open access to an API from any application may
result in security vulnerabilities.
例えば、APIを通してモバイルIPv6実装からIPsec実装までそのようなアドレス変化を実装することができます。 ホームのエージェントによって受け取られて、IPsecの使用で保護されたBinding Updatesに基づいてそのようなAPIの使用とアドレス変化をするだけでよいことに注意されるべきです。 他のソースに基づく通信員ノードへのBinding Updatesなどのアドレス変更が折り返し、routabilityを保護したか、またはどんなアプリケーションからのAPIへの開架もセキュリティの脆弱性をもたらすかもしれません。
Arkko, et al. Standards Track [Page 14] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[14ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
4.4. Dynamic Keying
4.4. ダイナミックな合わせること
The following requirements apply to both home agents and mobile nodes:
以下の要件はホームのエージェントとモバイルノードの両方に適用されます:
o If anti-replay protection is required, dynamic keying MUST be
used. IPsec can provide anti-replay protection only if dynamic
keying is used (which may not always be the case). IPsec also
does not guarantee correct ordering of packets, only that they
have not been replayed. Because of this, sequence numbers within
the Mobile IPv6 messages are used to ensure correct ordering.
However, if the 16 bit Mobile IPv6 sequence number space is cycled
through, or the home agent reboots and loses its state regarding
the sequence numbers, replay and reordering attacks become
possible. The use of dynamic keying, IPsec anti-replay
protection, and the Mobile IPv6 sequence numbers can together
prevent such attacks.
o 反反復操作による保護が必要であるなら、ダイナミックな合わせることを使用しなければなりません。 ダイナミックな合わせるのが使用されている場合にだけ(いつもケースであるかもしれないというわけではありません)、IPsecは反反復操作による保護を提供できます。 IPsecもパケットの正しい注文を保証しないで、それらは再演されているだけではありません。 これのために、モバイルIPv6メッセージの中の一連番号は、正しい注文を確実にするのに使用されます。 しかしながら、16ビットのモバイルIPv6一連番号スペースを循環するか、ホームのエージェントが一連番号に関して状態をリブートして、失うなら、再生と再命令攻撃は可能になります。 ダイナミックな合わせることの使用、IPsec反反復操作による保護、および一緒にモバイルIPv6一連番号缶はそのような攻撃を防ぎます。
o If IKE version 1 is used with preshared secrets in main mode, it
determines the shared secret to use from the IP address of the
peer. With Mobile IPv6, however, this may be a care-of address
and does not indicate which mobile node attempts to contact the
home agent. Therefore, if preshared secret authentication is used
in IKEv1 between the mobile node and the home agent then
aggressive mode MUST be used. Note also that care needs to be
taken with phase 1 identity selection. Where the ID_IPV6_ADDR
Identity Payloads is used, unambiguous mapping of identities to
keys is not possible. (The next version of IKE may not have these
limitations.)
o IKEバージョン1が主なモードによる前共有された秘密と共に使用されるなら、それは同輩のIPアドレスから使用への共有秘密キーを決定します。 そして、しかしながら、モバイルIPv6と共に、これがそうである、注意、-、アドレス、どのモバイルノードが、ホームのエージェントに連絡するのを試みるかを示しません。 したがって、前共有された秘密の認証がモバイルノードとホームのエージェントの間でIKEv1で使用されるなら、攻撃的なモードを使用しなければなりません。 また、注意が、フェーズの1つのアイデンティティの選択で取られる必要に注意してください。 ID_IPV6_ADDR Identity有効搭載量が使用されているところでは、キーへのアイデンティティの明白なマッピングは可能ではありません。 (IKEの次のバージョンには、これらの制限がないかもしれません。)
Note that the difficulties with main mode and preshared secrets in IKE version 1 are well known for dynamic addresses. With static addresses, there has not been a problem. With Mobile IPv6, however, the use of the care-of addresses to run IKE to the home agent presents a problem even when the home address stays stable. Further discussion about the use of care-of addresses in this way appears in Section 7.
ダイナミックなアドレスにおいて、主なモードと前共有された秘密がIKEバージョン1にある困難がよく知られていることに注意してください。 静的なアドレスと共に、問題がありませんでした。 しかしながら、モバイルIPv6、使用、注意、-、ホームアドレスが安定していた状態で残っていると、ホームのエージェントにIKEを実行するアドレスは問題を提示します。 使用についての議論を促進する、注意、-、中のこの道がセクション7で見えるアドレス
The following rules apply to mobile nodes:
以下の規則はモバイルノードに適用されます:
o In addition to the rules above, if dynamic keying is used, the key
management protocol MUST use the care-of address as the source
address in the protocol exchanges with the mobile node's home
agent.
o ダイナミックな合わせるのが使用されているなら、上では、規則に加えてかぎ管理プロトコルが使用されなければならない、注意、-、ソースアドレスとして、プロトコルでは、モバイルノードのホームのエージェントと共に交換を扱ってください。
Arkko, et al. Standards Track [Page 15] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[15ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
o However, the IPsec security associations with the mobile node's
home agent use home addresses. That is, the IPsec security
associations MUST be requested from the key management protocol
using the home address of the mobile node as the client identity.
o しかしながら、モバイルノードのホームのエージェントとのIPsecセキュリティ仲間はホームアドレスを使用します。 クライアントのアイデンティティとしてモバイルノードに関するホームアドレスを使用して、かぎ管理プロトコルからすなわち、IPsecセキュリティ協会を要求しなければなりません。
The security associations for protecting Binding Updates and
Acknowledgements are requested for the Mobility header protocol in
transport mode and for specific IP addresses as endpoints. No
other selectors are used. Similarly, the security associations
for protecting prefix discovery are requested for the ICMPv6
protocol and the specific IP addresses, again without other
selectors. Security associations for payload and return
routability protection are requested for a specific tunnel
interface and either the payload protocol or the Mobility header
protocol, in tunnel mode. In this case one requested endpoint is
an IP address and the other one is a wildcard, and there are no
other selectors.
Binding UpdatesとAcknowledgementsを保護するためのセキュリティ協会は交通機関によるMobilityヘッダープロトコルと終点としての特定のIPアドレスのために要求されています。 他のどんなセレクタも使用されていません。 同様に、接頭語発見を保護するためのセキュリティ協会はICMPv6プロトコルと特定のIPアドレスのために要求されています、再び他のセレクタなしで。 ペイロードのためのセキュリティ協会とリターンroutability保護は特定のトンネルのインタフェースとペイロードプロトコルかMobilityヘッダープロトコルのどちらかのために要求されています、トンネルモードで。 この場合、1つの要求された終点がIPアドレスです、そして、もう片方がワイルドカードです、そして、他のセレクタが全くありません。
o If the mobile node has used IKE version 1 to establish security
associations with its home agent, it should follow the procedures
discussed in Section 11.7.1 and 11.7.3 of the base specification
[7] to determine whether the IKE endpoints can be moved or if IKE
phase 1 has to be re-established.
o モバイルノードがホームのエージェントとのセキュリティ仲間を証明するのにIKEバージョン1を使用したなら、セクション11.7.1で議論した手順に従うべきです、そして、11.7に、IKE終点を動かすことができるか、またはIKEが1の位相を合わせるなら、決定する.3の基礎仕様[7]が復職しなければなりません。
The following rules apply to home agents:
以下の規則はホームのエージェントに適用されます:
o If the home agent has used IKE version 1 to establish security
associations with the mobile node, it should follow the procedures
discussed in Section 10.3.1 and 10.3.2 of the base specification
[7] to determine whether the IKE endpoints can be moved or if IKE
phase 1 has to be re-established.
o ホームのエージェントがモバイルノードとのセキュリティ協会を証明するのにIKEバージョン1を使用したなら、セクション10.3.1で議論した手順に従うべきです、そして、10.3に、IKE終点を動かすことができるか、またはIKEが1の位相を合わせるなら、決定する.2の基礎仕様[7]が復職しなければなりません。
5. Example Configurations
5. 例の構成
In the following we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect Binding Updates and Binding Acknowledgements exchanged between the mobile node and the home agent.
以下では、私たちはモバイルノードとホームのエージェントの間で交換されたBinding UpdatesとBinding Acknowledgementsを保護するのに必要なSecurity Policy Database(SPD)とSecurity Association Database(SAD)エントリーについて説明します。
Section 5.1 introduces the format we use in the description of the SPD and the SAD. Section 5.2 describes how to configure manually keyed IPsec security associations without dynamic keying, and Section 5.3 describes how to use dynamic keying.
セクション5.1は私たちがSPDとSADの記述に使用する形式を導入します。 セクション5.2はダイナミックな合わせるのなしで手動で合わせられたIPsecセキュリティ協会を構成する方法を説明します、そして、セクション5.3はダイナミックな合わせることを使用する方法を説明します。
Arkko, et al. Standards Track [Page 16] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[16ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
5.1. Format
5.1. 形式
The format used in the examples is as follows. The SPD description has the format
例で使用される形式は以下の通りです。 SPD記述には、形式があります。
<node> "SPD OUT:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
「以下からのSPD」という<ノード>。 「--」<spdentry>「-」<spdentry>… 「--」<spdentry>。
<node> "SPD IN:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
「以下のSPD」という<ノード>。 「--」<spdentry>「-」<spdentry>… 「--」<spdentry>。
Where <node> represents the name of the node, and <spdentry> has the following format:
<ノード>がノードの名前を表して、<spdentry>が以下の形式を持っているところ:
"IF" <condition> "THEN USE SA " <sa> |
"IF" <condition> "THEN USE SA " <pattern> |
「そして、SAを使用してください」という"IF"<状態><sa>。| 「そして、SAを使用してください」という"IF"<状態><パターン>。|
Where <condition> is a boolean expression about the fields of the IPv6 packet, <sa> is the name of a specific security association, and <pattern> is a specification for a security association to be negotiated via IKE [4]. The SAD description has the format
<状態>がIPv6パケットの分野に関する論理演算子式であるところでは、<sa>は特定のセキュリティ協会の名前です、そして、<パターン>はIKE[4]を通して交渉されるべきセキュリティ協会のための仕様です。 SAD記述には、形式があります。
<node> "SAD:"
"-" <sadentry>
"-" <sadentry>
...
"-" <sadentry>
<ノード>、「悲しい:、」 「--」<sadentry>「-」<sadentry>… 「--」<sadentry>。
Where <node> represents the name of the node, and <sadentry> has the following format:
<ノード>がノードの名前を表して、<sadentry>が以下の形式を持っているところ:
<sa> "(" <dir> ","
<spi> ","
<destination> ","
<ipsec-proto> ","
<mode> ")" ":"
<rule>
「<sa>、「(」 「<dir>」、<spi>、」、」 <の目的地>、」、」 <ipsec-proto>、」、」 <モード>、」、)、」、」、:、」 <規則>。
Arkko, et al. Standards Track [Page 17] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[17ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Where <dir> is "IN" or "OUT", <spi> is the SPI of the security association, <destination> is its destination, <ipsec-proto> is in our case "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <rule> is an expression which describes the IPsec selectors, i.e., which fields of the IPv6 packet must have which values.
<dir>が「IN」か“OUT"であり、<spi>がセキュリティ協会のSPIであり、<の目的地>が目的地であり、私たちのケース「超能力」には<ipsec-プロト>があって、<モード>が「トンネル」か「輸送」のどちらかであり、<規則>がすなわち、IPv6パケットのその分野にその値がなければならないIPsecセレクタについて説明する式であるところ。
We will be using an example mobile node in this section with the home address "home_address_1". The user's identity in this mobile node is "user_1". The home agent's address is "home_agent_1".
私たちはこのセクションの「ホーム_アドレス_1インチ」というホームアドレスがある例のモバイルノードを使用するでしょう。 このモバイルノードのユーザのアイデンティティは「ユーザ_1インチ」です。 ホームのエージェントのアドレスは「ホーム_エージェント_1インチ」です。
5.2. Manual Configuration
5.2. 手動の構成
5.2.1. Binding Updates and Acknowledgements
5.2.1. 拘束力があるアップデートと承認
Here are the contents of the SPD and SAD for protecting Binding Updates and Acknowledgements:
ここに、Binding UpdatesとAcknowledgementsを保護するためのSPDとSADの内容があります:
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA SA1
モバイルノードSPD OUT: - ソース=ホーム_アドレス_1と目的地=ホーム_エージェント_1とprotoがMH THEN USE SA SA1と等しいなら
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA SA2
モバイルノードSPD IN: - ソース=ホーム_エージェント_1と目的地がホーム_アドレス_1と等しく、protoがMH THEN USE SA SA2と等しいなら
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
モバイルノードSAD: - SA1(OUT、spi、ホーム_エージェント_1、超能力、TRANSPORT): ソース=ホーム_アドレス_1と目的地=ホーム_エージェント_1とprotoはMHと等しいです--、SA2(IN、spi_b、ホーム_アドレス_1、超能力、TRANSPORT): ソース=ホーム_エージェント_1と目的地はホーム_アドレス_1と等しいです、そして、protoはMHと等しいです。
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA SA2
ホームのエージェントSPD OUT: - ソース=ホーム_エージェント_1と目的地がホーム_アドレス_1と等しく、protoがMH THEN USE SA SA2と等しいなら
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA SA1
ホームのエージェントSPD IN: - ソース=ホーム_アドレス_1と目的地=ホーム_エージェント_1とprotoがMH THEN USE SA SA1と等しいなら
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
ホームのエージェントSAD: - SA2(OUT、spi_b、ホーム_アドレス_1、超能力、TRANSPORT): ソース=ホーム_エージェント_1と目的地はホーム_アドレス_1と等しいです。
Arkko, et al. Standards Track [Page 18] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[18ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
proto = MH
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
protoはMHと等しいです--、SA1(IN、spi、ホーム_エージェント_1、超能力、TRANSPORT): ソース=ホーム_アドレス_1と目的地=ホーム_エージェント_1とprotoはMHと等しいです。
In the above, "MH" refers to the protocol number for the Mobility Header [7].
上記では、"MH"は移動性ヘッダー[7]のプロトコル番号を示します。
5.2.2. Return Routability Signaling
5.2.2. リターンRoutabilityシグナリング
In the following we describe the necessary SPD and SAD entries to protect return routability signaling between the mobile node and the home agent. Note that the rules in the SPD are ordered, and the ones in the previous section must take precedence over these ones. In other words, the higher precedence entries must occur first in the RFC 2401 [2] ordered list of SPD entries.
以下では、私たちは、モバイルノードとホームのエージェントの間で合図するリターンroutabilityを保護するために必要なSPDとSADエントリーについて説明します。 SPDの規則が注文されて、前項のこれらのものの上で優先しなければならないことに注意してください。 言い換えれば、より高い先行エントリーは最初に、SPDエントリーのRFC2401の[2]の規則正しいリストに現れなければなりません。
mobile node SPD OUT:
- IF interface = IPv6 IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA SA3
モバイルノードSPD OUT: - インタフェース=IPv6 IPv6が_エージェント_1にホームにトンネルを堀って、ソース=ホーム_アドレス_1と目的地がいずれかと等しく、protoがMH THEN USE SA SA3と等しいなら
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA SA4
モバイルノードSPD IN: - インタフェース=IPv6がホーム_エージェント_1とソース=いずれかからトンネルを堀って、送付先=ホーム_アドレス_1とprotoがMH THEN USE SA SA4と等しいなら
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
モバイルノードSAD: - SA3(OUT、spi_c、ホーム_エージェント_1、超能力、TUNNEL): ソース=ホーム_アドレス_1と目的地はいずれとも等しいです、そして、protoはMHと等しいです--、SA4(TUNNEL、IN、spiは_アドレス_1、超能力の_について気にかけます): ソース=の送付先=ホーム_アドレスのいずれ、_1、およびprotoはMHと等しいです。
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA SA4
ホームのエージェントSPD OUT: - インタフェース=IPv6がソース=のホーム_アドレス_1、いずれか、および目的地=ホーム_にアドレス_1にトンネルを堀って、protoがMH THEN USE SA SA4と等しいなら
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA SA3
ホームのエージェントSPD IN: - インタフェース=IPv6がホーム_アドレス_1からトンネルを堀って、ソース=ホーム_アドレス_1と目的地がいずれかと等しく、protoがMH THEN USE SA SA3と等しいなら
Arkko, et al. Standards Track [Page 19] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[19ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
ホームのエージェントSAD: - SA4(TUNNEL、OUT(spi)は_アドレス_1、超能力の_について気にかけます): ソース=の送付先=ホーム_アドレスのいずれ、_1、およびprotoはMHと等しいです--、SA3(IN、spi_c、ホーム_エージェント_1、超能力、TUNNEL): ソース=ホーム_アドレス_1と目的地はいずれとも等しいです、そして、protoはMHと等しいです。
The security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves. It can be initialized to the home address before the mobile node has registered.
ホームのエージェントからモバイルノードまでのセキュリティ協会が電流を使用する、注意、-、目的地としてのアドレス。 以前に検討したことであるが、モバイルノードが移行するとき、SADでこのアドレスをアップデートします。 モバイルノードが登録する前にそれをホームアドレスに初期化できます。
5.2.3. Prefix Discovery
5.2.3. 接頭語発見
In the following we describe some additional SPD and SAD entries to protect prefix discovery. Note that the SPDs described above protect all ICMPv6 traffic between the mobile node and the home agent, as IPsec may not have the ability to distinguish between different ICMPv6 types.
以下では、私たちは、接頭語発見を保護するためにいくつかの追加SPDとSADエントリーについて説明します。 上で説明されたSPDsがモバイルノードとホームのエージェントの間のすべてのICMPv6トラフィックを保護することに注意してください、IPsecに異なったICMPv6タイプを見分ける能力がないとき。
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA SA5.
モバイルノードSPD OUT: - _ソース=ホーム_アドレス_1と目的地がホームと等しいなら、エージェント_1とprotoはICMPv6 THEN USE SA SA5と等しいです。
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA SA6
モバイルノードSPD IN: - ソース=ホーム_エージェント_1と目的地がホーム_アドレス_1と等しく、protoがICMPv6 THEN USE SA SA6と等しいなら
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
モバイルノードSAD: - SA5(OUT、spi_e、ホーム_エージェント_1、超能力、TRANSPORT): ソース=ホーム_アドレス_1と目的地=ホーム_エージェント_1とprotoはICMPv6と等しいです--、SA6(IN、spi_f、ホーム_アドレス_1、超能力、TRANSPORT): ソース=ホーム_エージェント_1と目的地はホーム_アドレス_1と等しいです、そして、protoはICMPv6と等しいです。
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA SA6
ホームのエージェントSPD OUT: - ソース=ホーム_エージェント_1と目的地がホーム_アドレス_1と等しく、protoがICMPv6 THEN USE SA SA6と等しいなら
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA SA5
ホームのエージェントSPD IN: - ソース=ホーム_アドレス_1と目的地=ホーム_エージェント_1とprotoがICMPv6 THEN USE SA SA5と等しいなら
Arkko, et al. Standards Track [Page 20] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[20ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
ホームのエージェントSAD: - SA6(OUT、spi_f、ホーム_アドレス_1、超能力、TRANSPORT): ソース=ホーム_エージェント_1と目的地はホーム_アドレス_1と等しいです、そして、protoはICMPv6と等しいです--、SA5(IN、spi_e、ホーム_エージェント_1、超能力、TRANSPORT): ソース=ホーム_アドレス_1と目的地=ホーム_エージェント_1とprotoはICMPv6と等しいです。
5.2.4. Payload Packets
5.2.4. 有効搭載量パケット
It is also possible to perform some additional, optional, protection of tunneled payload packets. This protection takes place in a similar manner to the return routability protection above, but requires a different value for the protocol field. The necessary SPD and SAD entries are shown below. It is assumed that the entries for protecting Binding Updates and Acknowledgements, and the entries to protect Home Test Init and Home Test messages take precedence over these entries.
また、トンネルを堀られたペイロードパケットの何らかの追加していて、任意の保護を実行するのも可能です。 この保護は、上で同じようにリターンroutability保護に行われますが、プロトコル分野に異価を必要とします。 必要なSPDとSADエントリーは以下で見せられます。 それが想定される、それ、Testメッセージがこれらのエントリーに優先するホームTest Initとホームを保護するためにBinding Updates、Acknowledgements、およびエントリーを保護するためのエントリー。
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA SA7
モバイルノードSPD OUT: - インタフェース=IPv6が_エージェント_1にホームにトンネルを堀って、ソース=ホーム_アドレス_1と目的地がいずれかと等しく、protoがX THEN USE SA SA7と等しいなら
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA SA8
モバイルノードSPD IN: - インタフェース=IPv6がホーム_エージェント_1とソース=いずれかからトンネルを堀って、送付先=ホーム_アドレス_1とprotoがX THEN USE SA SA8と等しいなら
mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
モバイルノードSAD: - SA7(OUT、spi_g、ホーム_エージェント_1、超能力、TUNNEL): ソース=ホーム_アドレス_1と目的地はいずれとも等しいです、そして、protoはXと等しいです--、SA8(TUNNEL、IN、spi_hは_アドレス_1、超能力の_について気にかけます): ソース=の送付先=ホーム_アドレスのいずれ、_1、およびprotoはXと等しいです。
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA SA8
ホームのエージェントSPD OUT: - インタフェース=IPv6がソース=のホーム_アドレス_1、いずれか、および目的地=ホーム_にアドレス_1にトンネルを堀って、protoがX THEN USE SA SA8と等しいなら
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA SA7
ホームのエージェントSPD IN: - インタフェース=IPv6がホーム_アドレス_1からトンネルを堀って、ソース=ホーム_アドレス_1と目的地がいずれかと等しく、protoがX THEN USE SA SA7と等しいなら
Arkko, et al. Standards Track [Page 21] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[21ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
home agent SAD:
- SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
ホームのエージェントSAD: - SA8(TUNNEL、OUT(spi_h)は_アドレス_1、超能力の_について気にかけます): ソース=の送付先=ホーム_アドレスのいずれ、_1、およびprotoはXと等しいです--、SA7(IN、spi_g、ホーム_エージェント_1、超能力、TUNNEL): ソース=ホーム_アドレス_1と目的地はいずれとも等しいです、そして、protoはXと等しいです。
If multicast group membership control protocols such as MLDv1 [9] or MLDv2 [11] need to be protected, these packets may use a link-local address rather than the home address of the mobile node. In this case the source and destination can be left as a wildcard and the SPD entries will work solely based on the used interface and the protocol, which is ICMPv6 for both MLDv1 and MLDv2.
MLDv1[9]かMLDv2[11]などのマルチキャストグループ会員資格制御プロトコルが、保護される必要があるなら、これらのパケットはモバイルノードに関するホームアドレスよりむしろリンクローカルアドレスを使用するかもしれません。 この場合、ワイルドカードとSPDエントリーが唯一中古のインタフェースとプロトコルに基づいて動作するとき、ソースと目的地を出ることができます。プロトコルはMLDv1とMLDv2の両方のためのICMPv6です。
Similar problems are encountered when stateful address autoconfiguration protocols such as DHCPv6 [10] are used. The same approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP protocol.
DHCPv6[10]などのstatefulアドレス自動構成プロトコルが使用されているとき、同様の問題は行きあたられます。 また、DHCPv6に、同じアプローチは適切です。 DHCPv6はUDPプロトコルを使用します。
Support for multiple layers of encapsulation (such as ESP encapsulated in ESP) is not required by RFC 2401 [2] and is also otherwise often problematic. It is therefore useful to avoid setting the protocol X in the above entries to either AH or ESP.
RFC2401[2]は必要ではありません。また、そうでなければ、複数の層のカプセル化(超能力でカプセル化された超能力などの)のサポートも、しばしば問題が多いです。 したがって、AHか超能力のどちらかへの上のエントリーにプロトコルXをはめ込むのを避けるのは役に立ちます。
5.3. Dynamic Keying
5.3. ダイナミックな合わせること
In this section we show an example configuration that uses IKE to negotiate security associations.
このセクションで、私たちはセキュリティ協会を交渉するのにIKEを使用する例の構成を示しています。
5.3.1. Binding Updates and Acknowledgements
5.3.1. 拘束力があるアップデートと承認
Here are the contents of the SPD for protecting Binding Updates and Acknowledgements:
ここに、Binding UpdatesとAcknowledgementsを保護するためのSPDの内容があります:
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
モバイルノードSPD OUT: - _ソース=ホーム_アドレス_1と目的地がホームと等しいなら、エージェント_1とprotoはMH THEN USE SA ESP TRANSPORTと等しいです: 地方のフェーズ1のアイデンティティはユーザ_1と等しいです。
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
モバイルノードSPD IN: - _ソース=ホーム_エージェント_1と目的地がホームと等しいなら、アドレス_1とprotoはMH THEN USE SA ESP TRANSPORTと等しいです: 地方のフェーズ1のアイデンティティはユーザ_1と等しいです。
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
ホームのエージェントSPD OUT: - _ソース=ホーム_エージェント_1と目的地がホームと等しいなら、アドレス_1とprotoはMH THEN USE SA ESP TRANSPORTと等しいです: 同輩フェーズ1のアイデンティティはユーザ_1と等しいです。
Arkko, et al. Standards Track [Page 22] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[22ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
ホームのエージェントSPD IN: - _ソース=ホーム_アドレス_1と目的地がホームと等しいなら、エージェント_1とprotoはMH THEN USE SA ESP TRANSPORTと等しいです: 同輩フェーズ1のアイデンティティはユーザ_1と等しいです。
We have omitted details of the proposed transforms in the above, and all details related to the particular authentication method such as certificates beyond listing a specific identity that must be used.
私たちは上記の提案された変換の詳細を省略しました、そして、すべての詳細が使用されていた状態で特定のアイデンティティを記載することを超えたそうしなければならない証明書のような特定の認証方法に関連しました。
We require IKE version 1 to be run using the care-of addresses but still negotiate IPsec SAs that use home addresses. The extra conditions set by the home agent SPD for the peer phase 1 identity to be "user_1" must be verified by the home agent. The purpose of the condition is to ensure that the IKE phase 2 negotiation for a given user's home address can not be requested by another user. In the mobile node, we simply set our local identity to be "user_1".
私たちが走行使用になるようにIKEバージョン1を必要とする、注意、-、まだホームアドレスを使用するIPsec SAsを交渉しているのを除いて、扱います。 ホームのエージェントSPDによって同輩に出された付加的な条件は、「ホームのエージェントはユーザ_1インチについて確かめなければならない」ということになるように1つのアイデンティティの位相を合わせます。 状態の目的は別のユーザが与えられたユーザのホームアドレスのためのIKEフェーズ2交渉を要求できないのを保証することです。 モバイルノードでは、私たちは、地元のアイデンティティに「ユーザ_1インチ」であるように単に設定します。
These checks also imply that the configuration of the home agent is user-specific: every user or home address requires a specific configuration entry. It would be possible to alleviate the configuration tasks by using certificates that have home addresses in the Subject AltName field. However, it is not clear if all IKE implementations allow one address to be used for carrying the IKE negotiations when another address is mentioned in the used certificates. In any case, even this approach would have required user-specific tasks in the certification authority.
また、これらのチェックは、ホームのエージェントの構成がユーザ特有であることを含意します: あらゆるユーザかホームアドレスが特定の構成エントリーを必要とします。 Subject AltName分野にホームアドレスを持っている証明書を使用することによって構成タスクを軽減するのは可能でしょう。 しかしながら、別のアドレスがいつ中古の証明書で参照されるかは、すべてのIKE実装が、1つのアドレスがIKE交渉を運ぶのに使用されるのを許容するかどうか明確ではありません。 このアプローチさえ証明権威におけるユーザ特有のタスクを必要としたでしょう。
5.3.2. Return Routability Signaling
5.3.2. リターンRoutabilityシグナリング
Protection for the return routability signaling can be configured in a similar manner as above.
同じように同じくらい上でリターンroutabilityシグナリングのための保護を構成できます。
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
モバイルノードSPD OUT: - = インタフェース=IPv6がホーム_エージェント_1とソース=ホーム_アドレス_1と目的地にトンネルを堀るなら、いずれとprotoはMH THEN USE SA ESP TUNNELと等しいです: 外側の目的地=ホーム_エージェント_1と地方のフェーズ1のアイデンティティはユーザ_1と等しいです。
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
モバイルノードSPD IN: - = インタフェース=IPv6がホーム_エージェント_1とソースからトンネルを堀るなら、いずれと目的地=ホーム_アドレス_1とprotoはMH THEN USE SA ESP TUNNELと等しいです: 外側の目的地=ホーム_エージェント_1と地方のフェーズ1のアイデンティティはユーザ_1と等しいです。
Arkko, et al. Standards Track [Page 23] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[23ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
ホームのエージェントSPD OUT: - = インタフェース=IPv6がホーム_アドレス_1とソースにトンネルを堀るなら、いずれと目的地=ホーム_アドレス_1とprotoはMH THEN USE SA ESP TUNNELと等しいです: 外側の目的地の=ホーム_アドレス_1と同輩フェーズ1のアイデンティティはユーザ_1と等しいです。
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
ホームのエージェントSPD IN: - = インタフェース=IPv6がホーム_アドレス_1とソース=ホーム_アドレス_1と目的地からトンネルを堀るなら、いずれとprotoはMH THEN USE SA ESP TUNNELと等しいです: 外側の目的地の=ホーム_アドレス_1と同輩フェーズ1のアイデンティティはユーザ_1と等しいです。
The security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves. The SPD entries can be written using the home address (as above), if the care-of address update in the SAD is also done upon the creation of security associations.
ホームのエージェントからモバイルノードまでのセキュリティ協会が電流を使用する、注意、-、目的地としてのアドレス。 以前に検討したことであるが、モバイルノードが移行するとき、SADでこのアドレスをアップデートします。 ホームアドレス(as above)を使用することでSPDエントリーを書くことができる、注意、-、また、セキュリティ協会の創設でSADのアドレス最新版をします。
5.3.3. Prefix Discovery
5.3.3. 接頭語発見
In the following we describe some additional SPD entries to protect prefix discovery with IKE. (Note that when actual new prefixes are discovered, there may be a need to enter new manually configured SPD entries to specify the authorization policy for the resulting new home addresses.)
以下では、私たちは、IKEとの接頭語発見を保護するためにいくつかの追加SPDエントリーについて説明します。 (実際の新しい接頭語が発見されるとき、結果として起こる新しいホームアドレスに承認方針を指定するために手動で構成された新しいSPDエントリーに入る必要があるかもしれないことに注意してください。)
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
モバイルノードSPD OUT: - _ソース=ホーム_アドレス_1と目的地がホームと等しいなら、エージェント_1とprotoはICMPv6 THEN USE SA ESP TRANSPORTと等しいです: 地方のフェーズ1のアイデンティティはユーザ_1と等しいです。
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
モバイルノードSPD IN: - _ソース=ホーム_エージェント_1と目的地がホームと等しいなら、アドレス_1とprotoはICMPv6 THEN USE SA ESP TRANSPORTと等しいです: 地方のフェーズ1のアイデンティティはユーザ_1と等しいです。
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
ホームのエージェントSPD OUT: - _ソース=ホーム_エージェント_1と目的地がホームと等しいなら、アドレス_1とprotoはICMPv6 THEN USE SA ESP TRANSPORTと等しいです: 同輩フェーズ1のアイデンティティはユーザ_1と等しいです。
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
ホームのエージェントSPD IN: - _ソース=ホーム_アドレス_1と目的地がホームと等しいなら、エージェント_1とprotoはICMPv6 THEN USE SA ESP TRANSPORTと等しいです: 同輩フェーズ1のアイデンティティはユーザ_1と等しいです。
Arkko, et al. Standards Track [Page 24] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[24ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
5.3.4. Payload Packets
5.3.4. 有効搭載量パケット
Protection for the payload packets happens similarly to the protection of return routability signaling. As in the manually keyed case, these SPD entries have lower priority than the above ones.
ペイロードパケットのための保護は同様にリターンroutabilityシグナリングの保護に起こります。 手動で合わせられたケースのように、これらのSPDエントリーには上のものより低い優先度があります。
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
モバイルノードSPD OUT: - = インタフェース=IPv6がホーム_エージェント_1とソース=ホーム_アドレス_1と目的地にトンネルを堀るなら、いずれとprotoはX THEN USE SA ESP TUNNELと等しいです: 外側の目的地=ホーム_エージェント_1と地方のフェーズ1のアイデンティティはユーザ_1と等しいです。
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
モバイルノードSPD IN: - = インタフェース=IPv6がホーム_エージェント_1とソースからトンネルを堀るなら、いずれと目的地=ホーム_アドレス_1とprotoはX THEN USE SA ESP TUNNELと等しいです: 外側の目的地=ホーム_エージェント_1と地方のフェーズ1のアイデンティティはユーザ_1と等しいです。
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
ホームのエージェントSPD OUT: - = インタフェース=IPv6がホーム_アドレス_1とソースにトンネルを堀るなら、いずれと目的地=ホーム_アドレス_1とprotoはX THEN USE SA ESP TUNNELと等しいです: 外側の目的地の=ホーム_アドレス_1と同輩フェーズ1のアイデンティティはユーザ_1と等しいです。
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
ホームのエージェントSPD IN: - = インタフェース=IPv6がホーム_アドレス_1とソース=ホーム_アドレス_1と目的地からトンネルを堀るなら、いずれとprotoはX THEN USE SA ESP TUNNELと等しいです: 外側の目的地の=ホーム_アドレス_1と同輩フェーズ1のアイデンティティはユーザ_1と等しいです。
6. Processing Steps within a Node
6. ノードの中の処理ステップ
6.1. Binding Update to the Home Agent
6.1. ホームのエージェントへの拘束力があるアップデート
Step 1. At the mobile node, Mobile IPv6 module first produces the following packet:
1を踏んでください。 モバイルノードでは、モバイルIPv6モジュールは最初に、以下のパケットを作り出します:
IPv6 header (source = home address,
destination = home agent)
Mobility header
Binding Update
IPv6ヘッダー(目的地=ホームエージェント、ソースはホームアドレスと等しい)移動性ヘッダーBinding Update
Step 2. This packet is matched against the IPsec SPD on the mobile node and we make a note that IPsec must be applied.
2を踏んでください。 このパケットはモバイルノードの上のIPsec SPDに取り組まされます、そして、私たちはIPsecを適用しなければならないというメモを作ります。
Arkko, et al. Standards Track [Page 25] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[25ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Step 3. Then, we add the necessary Mobile IPv6 options but do not change the addresses yet, as described in Section 11.3.2 of the base specification [7]. This results in:
3を踏んでください。 次に、私たちは、必要なモバイルIPv6オプションを加えますが、まだアドレスを変えていません、.2のセクション11.3基礎仕様[7]で説明されるように。 これは以下に結果として生じます。
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding Update
IPv6ヘッダー(ソースはホームアドレスと等しいです、目的地=ホームエージェント)目的地OptionsヘッダーホームAddressオプション、(注意、-、アドレス) 移動性ヘッダーBinding Update
Step 4. Finally, IPsec headers are added and the necessary authenticator values are calculated:
4を踏んでください。 最終的に、IPsecヘッダーは加えられます、そして、必要な固有識別文字値は計算されます:
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
ESP header (SPI = spi_a)
Mobility header
Binding Update
IPv6ヘッダー(ソースはホームアドレスと等しいです、目的地=ホームエージェント)目的地OptionsヘッダーホームAddressオプション、(注意、-、アドレス) 超能力ヘッダー(SPIはspiと等しい)移動性ヘッダーBinding Update
Here spi_a is the SPI value that was either configured manually, or agreed upon in an earlier IKE negotiation.
ここで、spiは以前のIKE交渉で手動で構成されたか、または同意したSPI値です。
Step 5. Before sending the packet, the addresses in the IPv6 header and the Destination Options header are changed:
5を踏んでください。 パケットを送る前に、IPv6ヘッダーとDestination Optionsヘッダーのアドレスを変えます:
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = spi_a)
Mobility header
Binding Update
IPv6ヘッダー、(ソース=、注意、-、アドレス、目的地=ホームエージェント) 目的地OptionsヘッダーホームAddressオプション(ホームアドレス)超能力ヘッダー(SPIはspiと等しい)移動性ヘッダーBinding Update
6.2. Binding Update from the Mobile Node
6.2. モバイルノードからの拘束力があるアップデート
Step 1. The following packet is received at the home agent:
1を踏んでください。 ホームのエージェントに以下のパケットを受け取ります:
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = spi_a)
Mobility header
Binding Update
IPv6ヘッダー、(ソース=、注意、-、アドレス、目的地=ホームエージェント) 目的地OptionsヘッダーホームAddressオプション(ホームアドレス)超能力ヘッダー(SPIはspiと等しい)移動性ヘッダーBinding Update
Arkko, et al. Standards Track [Page 26] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[26ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Step 2. The home address option is processed first, which results in
2を踏んでください。 ホームアドレスオプションは最初に、処理されます(中に結果として生じます)。
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
ESP header (SPI = spi_a)
Mobility header
Binding Update
IPv6ヘッダー(ソースはホームアドレスと等しいです、目的地=ホームエージェント)目的地OptionsヘッダーホームAddressオプション、(注意、-、アドレス) 超能力ヘッダー(SPIはspiと等しい)移動性ヘッダーBinding Update
Step 3. ESP header is processed next, resulting in
3を踏んでください。 中でなって、超能力ヘッダーは次に、処理されます。
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding Update
IPv6ヘッダー(ソースはホームアドレスと等しいです、目的地=ホームエージェント)目的地OptionsヘッダーホームAddressオプション、(注意、-、アドレス) 移動性ヘッダーBinding Update
Step 4. This packet matches the policy required for this security association (source = home address, destination = home agent, proto = MH).
4を踏んでください。 このパケットはこのセキュリティ協会に必要である方針に合っています(ソース=ホームアドレス、目的地=ホームエージェント、protoはMHと等しいです)。
Step 5. Mobile IPv6 processes the Binding Update. The Binding Update is delivered to the Mobile IPv6 module.
5を踏んでください。 モバイルIPv6はBinding Updateを処理します。 Binding UpdateはモバイルIPv6モジュールに提供されます。
Step 6. If there are any security associations in the security association database for the protection of return routability or payload packets for this mobile node, those security associations are updated with the new care-of address.
6を踏んでください。 何かセキュリティ協会がリターンroutabilityの保護のためのセキュリティ協会データベースかこのモバイルノードのためのペイロードパケットにあれば、新しさでそれらのセキュリティ協会をアップデートする、注意、-、アドレス。
6.3. Binding Acknowledgement to the Mobile Node
6.3. モバイルノードへの拘束力がある承認
Step 1. Mobile IPv6 produces the following packet:
1を踏んでください。 モバイルIPv6は以下のパケットを作り出します:
IPv6 header (source = home agent,
destination = home address)
Mobility header
Binding Acknowledgement
IPv6ヘッダー(ソース=ホームエージェント、目的地=ホームアドレス)移動性ヘッダーBinding Acknowledgement
Step 2. This packet matches the IPsec policy entries, and we remember that IPsec has to be applied.
2を踏んでください。 このパケットはIPsec方針エントリーに合っています、そして、IPsecは私たちによって忘れずに適用されなければなりません。
Arkko, et al. Standards Track [Page 27] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[27ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Step 3. Then, we add the necessary Route Headers but do not change the addresses yet, as described in Section 9.5.4 of the base specification [7]. This results in:
3を踏んでください。 次に、私たちは、必要なRoute Headersを加えますが、まだアドレスを変えていません、.4のセクション9.5基礎仕様[7]で説明されるように。 これは以下に結果として生じます。
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
Mobility header
Binding Acknowledgement
IPv6ヘッダー(ソース=ホームエージェント、目的地=ホームアドレス)ルート設定ヘッダー(2をタイプする)、注意、-、MobilityヘッダーがBinding Acknowledgementであると扱ってください。
Step 4. We apply IPsec:
4を踏んでください。 私たちはIPsecを適用します:
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement
IPv6ヘッダー(ソースはホームのエージェントと等しいです、目的地=ホームアドレス)ルート設定ヘッダー(2をタイプする)、注意、-、超能力ヘッダー(SPIはspi_bと等しい)移動性ヘッダーがBinding Acknowledgementであると扱ってください。
Step 5. Finally, before sending the packet out we change the addresses in the IPv6 header and the Route header:
5を踏んでください。 最終的に、パケットを出す前に、私たちはIPv6ヘッダーとRouteヘッダーでアドレスを変えます:
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement
IPv6ヘッダー、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、ヘッダー(タイプ2)ホームアドレス超能力ヘッダー(SPIはspi_bと等しい)移動性ヘッダーBinding Acknowledgementを発送すること。
6.4. Binding Acknowledgement from the Home Agent
6.4. ホームのエージェントからの拘束力がある承認
Step 1. The following packet is received at the mobile node
1を踏んでください。 モバイルノードに以下のパケットを受け取ります。
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement
IPv6ヘッダー、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、ヘッダー(タイプ2)ホームアドレス超能力ヘッダー(SPIはspi_bと等しい)移動性ヘッダーBinding Acknowledgementを発送すること。
Arkko, et al. Standards Track [Page 28] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[28ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Step 2. After the routing header is processed the packet becomes
2を踏んでください。 ルーティングヘッダーが処理された後に、パケットはなります。
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement
IPv6ヘッダー(ソースはホームのエージェントと等しいです、目的地=ホームアドレス)ルート設定ヘッダー(2をタイプする)、注意、-、超能力ヘッダー(SPIはspi_bと等しい)移動性ヘッダーがBinding Acknowledgementであると扱ってください。
Step 3. ESP header is processed next, resulting in:
3を踏んでください。 以下となって、超能力ヘッダーは次に、処理されます。
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
Mobility header
Binding Acknowledgement
IPv6ヘッダー(ソース=ホームエージェント、目的地=ホームアドレス)ルート設定ヘッダー(2をタイプする)、注意、-、MobilityヘッダーがBinding Acknowledgementであると扱ってください。
Step 4. This packet matches the policy required for this security association (source = home agent, destination = home address, proto = MH).
4を踏んでください。 このパケットはこのセキュリティ協会に必要である方針に合っています(ソース=ホームエージェント、目的地=ホームアドレス、protoはMHと等しいです)。
Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 module.
5を踏んでください。 Binding AcknowledgementはモバイルIPv6モジュールに提供されます。
6.5. Home Test Init to the Home Agent
6.5. ホームのエージェントへのホームテストイニット
Step 1. The mobile node constructs a Home Test Init message:
1を踏んでください。 モバイルノードはホームTest Initメッセージを構成します:
IPv6 header (source = home address,
destination = correspondent node)
Mobility header
Home Test Init
IPv6ヘッダー(ソース=ホームアドレス、目的地=通信員ノード)移動性ヘッダーホームTest Init
Step 2. Mobile IPv6 determines that this packet should go to the tunnel to the home agent.
2を踏んでください。 モバイルIPv6は、このパケットがトンネルにホームのエージェントのものになるはずであることを決定します。
Step 3. The packet is matched against IPsec policy entries for the interface, and we find that IPsec needs to be applied.
3を踏んでください。 パケットはインタフェースのためのIPsec方針エントリーに取り組まされました、そして、私たちはIPsecが、適用される必要であるのがわかりました。
Step 4. IPsec tunnel mode headers are added. Note that we use a care-of address as a source address for the tunnel packet.
4を踏んでください。 IPsecトンネルモードヘッダーは加えられます。 私たちがaを使用することに注意してください、注意、-、トンネルパケットのためのソースアドレスとしてのアドレス。
IPv6 header (source = care-of address,
destination = home agent)
ESP header (SPI = spi_c)
IPv6 header (source = home address,
目的地はホームのエージェント) 超能力ヘッダー(SPIはspi_cと等しい)IPv6ヘッダーと等しいです。IPv6ヘッダー、(ソース=、注意、-、アドレス、(ソースはホームアドレスと等しいです。
Arkko, et al. Standards Track [Page 29] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[29ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
destination = correspondent node)
Mobility header
Home Test Init
目的地=通信員ノード) 移動性ヘッダーホームTest Init
Step 5. The packet is sent directly to the home agent using IPsec encapsulation.
5を踏んでください。 IPsecカプセル化を使用することで直接ホームのエージェントにパケットを送ります。
6.6. Home Test Init from the Mobile Node
6.6. モバイルノードからのホームテストイニット
Step 1. The home agent receives the following packet:
1を踏んでください。 ホームのエージェントは以下のパケットを受けます:
IPv6 header (source = care-of address,
destination = home agent)
ESP header (SPI = spi_c)
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test Init
IPv6ヘッダー、(ソース=、注意、-、アドレス、目的地=ホームエージェント) 超能力ヘッダー(SPIはspi_cと等しい)IPv6ヘッダー(ソースはホームアドレスと等しいです、目的地=通信員ノード)移動性HeaderホームTest Init
Step 2. IPsec processing is performed, resulting in:
2を踏んでください。 以下となって、IPsec処理は実行されます。
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test Init
IPv6ヘッダー(ソース=ホームアドレス、目的地=通信員ノード)移動性HeaderホームTest Init
Step 3. The resulting packet matches the policy required for this security association and the packet can be processed further.
3を踏んでください。 さらに方針がこのセキュリティ協会とパケットのために必要とした結果として起こるパケットマッチを処理できます。
Step 4. The packet is then forwarded to the correspondent node.
4を踏んでください。 そして、通信員ノードにパケットを送ります。
6.7. Home Test to the Mobile Node
6.7. モバイルノードへのホームテスト
Step 1. The home agent receives a Home Test packet from the correspondent node:
1を踏んでください。 ホームのエージェントは通信員ノードからホームTestパケットを受けます:
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
IPv6ヘッダー(ソース=通信員ノード、目的地=ホームアドレス)移動性HeaderホームTest Init
Step 2. The home agent determines that this packet is destined to a mobile node that is away from home, and decides to tunnel it.
2を踏んでください。 ホームのエージェントは、このパケットが家にいないモバイルノードに運命づけられていると決心して、それにトンネルを堀ると決めます。
Step 3. The packet matches the IPsec policy entries for the tunnel interface, and we note that IPsec needs to be applied.
3を踏んでください。 パケットはトンネルのインタフェースのためのIPsec方針エントリーに合っています、そして、私たちはIPsecが、適用される必要に注意します。
Arkko, et al. Standards Track [Page 30] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[30ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Step 4. IPsec is applied, resulting in a new packet. Note that the home agent must keep track of the location of the mobile node, and update the tunnel endpoint address in the security association(s) accordingly.
4を踏んでください。 新しいパケットをもたらして、IPsecは適用されています。 ホームのエージェントがモバイルノードの位置の動向をおさえなければならないことに注意してください、そして、それに従って、セキュリティ協会でトンネル終点アドレスをアップデートしてください。
IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d)
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
IPv6ヘッダー、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、超能力ヘッダー(SPIはspiと等しい)IPv6ヘッダー(ソースは通信員ノードと等しいです、目的地=ホームアドレス)移動性HeaderホームTest Init
Step 5. The packet is sent directly to the care-of address using IPsec encapsulation.
5を踏んでください。 パケットに直送する、注意、-、使用がIPsecカプセル化であると扱ってください。
6.8. Home Test from the Home Agent
6.8. ホームのエージェントからのホームテスト
Step 1. The mobile node receives the following packet:
1を踏んでください。 モバイルノードは以下のパケットを受けます:
IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d)
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
IPv6ヘッダー、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、超能力ヘッダー(SPIはspiと等しい)IPv6ヘッダー(ソースは通信員ノードと等しいです、目的地=ホームアドレス)移動性HeaderホームTest Init
Step 2. IPsec is processed, resulting in:
2を踏んでください。 以下となって、IPsecは処理されます。
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
IPv6ヘッダー(ソース=通信員ノード、目的地=ホームアドレス)移動性HeaderホームTest Init
Step 3. This matches the policy required for this security association (source = any, destination = home address).
3を踏んでください。 これはこのセキュリティ協会に必要である方針に合っています(ソースはどんな、目的地=ホームアドレスとも等しいです)。
Step 4. The packet is given to Mobile IPv6 processing.
4を踏んでください。 モバイルIPv6処理にパケットを与えます。
6.9. Prefix Solicitation Message to the Home Agent
6.9. ホームのエージェントへの接頭語懇願メッセージ
This procedure is similar to the one presented in Section 6.1.
この手順はセクション6.1に提示されたものと同様です。
6.10. Prefix Solicitation Message from the Mobile Node
6.10. モバイルノードからの接頭語懇願メッセージ
This procedure is similar to the one presented in Section 6.2.
この手順はセクション6.2に提示されたものと同様です。
Arkko, et al. Standards Track [Page 31] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[31ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
6.11. Prefix Advertisement Message to the Mobile Node
6.11. モバイルノードへの接頭語広告メッセージ
This procedure is similar to the one presented in Section 6.3.
この手順はセクション6.3に提示されたものと同様です。
6.12. Prefix Advertisement Message from the Home Agent
6.12. ホームのエージェントからの接頭語広告メッセージ
This procedure is similar to the one presented in Section 6.4.
この手順はセクション6.4に提示されたものと同様です。
6.13. Payload Packet to the Home Agent
6.13. ホームのエージェントへの有効搭載量パケット
This procedure is similar to the one presented in Section 6.5.
この手順はセクション6.5に提示されたものと同様です。
6.14. Payload Packet from the Mobile Node
6.14. モバイルノードからの有効搭載量パケット
This procedure is similar to the one presented in Section 6.6.
この手順はセクション6.6に提示されたものと同様です。
6.15. Payload Packet to the Mobile Node
6.15. モバイルノードへの有効搭載量パケット
This procedure is similar to the one presented in Section 6.7.
この手順はセクション6.7に提示されたものと同様です。
6.16. Payload Packet from the Home Agent
6.16. ホームのエージェントからの有効搭載量パケット
This procedure is similar to the one presented in Section 6.8.
この手順はセクション6.8に提示されたものと同様です。
6.17. Establishing New Security Associations
6.17. 新しいセキュリティ協会を設立します。
Step 1. The mobile node wishes to send a Binding Update to the home agent.
1を踏んでください。 モバイルノードはホームのエージェントにBinding Updateを送りたがっています。
IPv6 header (source = home address,
destination = home agent)
Mobility header
Binding Update
IPv6ヘッダー(目的地=ホームエージェント、ソースはホームアドレスと等しい)移動性ヘッダーBinding Update
Step 2. There is no existing security association to protect the Binding Update, so the mobile node initiates IKE. The IKE packets are sent as shown in the following examples. The first packet is an example of an IKE packet sent from the mobile node, and the second one is from the home agent. The examples shows also that the phase 1 identity used for the mobile node is a FQDN.
2を踏んでください。 Binding Updateを保護するどんな既存のセキュリティ協会もないので、モバイルノードはIKEを開始します。 以下の例に示されるようにIKEパケットを送ります。 最初のパケットはモバイルノードから送られたIKEパケットに関する例です、そして、2番目のものはホームのエージェントから来ています。 また、例は、1つのアイデンティティがモバイルノードに使用したフェーズがFQDNであることを示します。
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDii = ID_FQDN mn123.ha.net ...
IPv6ヘッダー、(ソース=、注意、-、エージェント) アドレス、目的地=ホームUDP IKE… IDiiはID_FQDN mn123.ha.netと等しいです…
Arkko, et al. Standards Track [Page 32] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[32ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
IPv6 header (source = home agent
destination = care-of address)
UDP
IKE
... IDir = ID_FQDN ha.net ...
IPv6ヘッダー、(ソース=ホームエージェント目的地=、注意、-、アドレス) UDP IKE… IDirはID_FQDN ha.netと等しいです…
Step 3. IKE phase 1 completes, and phase 2 is initiated to request security associations for protecting traffic between the mobile node's home address and the home agent. These addresses will be used as selectors. This involves sending and receiving additional IKE packets. The below example shows again one packet sent by the mobile node and another sent by the home agent. The example shows also that the phase 2 identity used for the mobile node is the mobile node's home address.
3を踏んでください。 1が完成して、フェーズ2が開始されるIKEフェーズは、モバイルノードのホームアドレスとホームのエージェントの間のトラフィックを保護するためにセキュリティ協会を要求します。 これらのアドレスはセレクタとして使用されるでしょう。 これは、追加IKEパケットを送って、受けることを伴います。 以下の例は再びモバイルノードによって送られた1つのパケットとホームのエージェントによって送られた別のものを示しています。 また、例は、2のアイデンティティがモバイルノードに使用したフェーズがモバイルノードのホームアドレスであることを示します。
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDci = ID_IPV6_ADDR home address ...
IPv6ヘッダー、(ソース=、注意、-、エージェント) アドレス、目的地=ホームUDP IKE… IDciはID_IPV6_ADDRホームアドレスと等しいです…
IPv6 header (source = home agent,
destination = care-of address)
UDP
IKE
... IDcr = ID_IPV6_ADDR home agent ...
IPv6ヘッダー、(ソース=ホームエージェント、目的地=、注意、-、アドレス) UDP IKE… IDcrはID_IPV6_ADDRホームのエージェントと等しいです…
Step 4. The remaining steps are as shown in Section 6.1.
4を踏んでください。 残っているステップがセクション6.1に示されるようにあります。
6.18. Rekeying Security Associations
6.18. セキュリティ協会をRekeyingします。
Step 1. The mobile node and the home agent have existing security associations. Either side may decide at any time that the security associations need to be rekeyed, for instance, because the specified lifetime is approaching.
1を踏んでください。 モバイルノードとホームのエージェントには、既存のセキュリティ協会があります。 どちらの側も、いつでも、例えば、指定された寿命に近づくのでセキュリティ協会が、「再-合わせ」られる必要であると決めるかもしれません。
Step 2. Mobility header packets sent during rekey may be protected by the existing security associations.
2を踏んでください。 rekeyの間に送られた移動性ヘッダーパケットは既存のセキュリティ協会によって保護されるかもしれません。
Step 3. When the rekeying is finished, new security associations are established. In practice there is a time interval during which an old, about-to-expire security association and newly established security association will both exist. The new ones should be used as soon as they become available.
3を踏んでください。 「再-合わせ」るのが終わっているとき、新しいセキュリティ協会は設立されます。 実際には、古くて、周囲に吐き出しているセキュリティ協会と新設されたセキュリティ協会がともに存在する時間間隔があります。 利用可能になるとすぐに、新しい使用されるべきです。
Step 4. A notification of the deletion of the old security associations is received. After this, only the new security associations can be used.
4を踏んでください。 古いセキュリティ協会の削除の通知は受信されています。 この後、新しいセキュリティ協会しか使用できません。
Arkko, et al. Standards Track [Page 33] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[33ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Note that there is no requirement that the existence of the IPsec and IKE security associations is tied to the existence of bindings. It is not necessary to delete a security association if a binding is removed, as a new binding may soon be established after this.
IPsecとIKEセキュリティ協会の存在が結合の存在に結ばれるという要件が全くないことに注意してください。 結合を取り除くなら、セキュリティ協会を削除するのは必要ではありません、新しい結合がこの後すぐ確立されるとき。
Since cryptographic acceleration hardware may only be able to handle a limited number of active security associations, security associations may be deleted via IKE in order to keep the number of active cryptographic contexts to a minimum. Such deletions should not be interpreted as a sign of losing a contact to the peer or as a reason to remove a binding. Rather, if additional traffic needs to be sent, it is preferable to bring up another security association to protect it.
暗号の加速ハードウェアが限られた数の活動的なセキュリティ協会を扱うことができるだけであるかもしれないので、セキュリティ協会はアクティブな暗号の文脈の数を最小に抑えるためにIKEを通して削除されるかもしれません。 同輩に接触を失うサインとして、または、結合を取り除く理由としてそのような削除を解釈するべきではありません。 むしろ、追加トラフィックが、送られる必要があるなら、それを保護する別のセキュリティ協会を持って来るのは望ましいです。
6.19. Movements and Dynamic Keying
6.19. 運動とダイナミックな合わせること
In this section we describe the sequence of events that relate to movement with IKE-based security associations. In the initial state, the mobile node is not registered in any location and has no security associations with the home agent. Depending on whether the peers will be able to move IKE endpoints to new care-of addresses, the actions taken in Step 9 and 10 are different.
このセクションで、私たちはIKEを拠点とするセキュリティ関係と共に動きに関連するイベントの系列について説明します。 初期状態には、モバイルノードでは、どんな位置にも登録されないで、またセキュリティ協会が全くホームのエージェントと共にいません。 同輩がいるかどうかによる、IKE終点を動くことができる新しさ、注意、-、アドレス、Step9と10で取られた行動は異なっています。
Step 1. Mobile node with the home address A moves to care-of address B.
1を踏んでください。 Aが移行するホームアドレスがあるモバイルノード、注意、-、Bを扱ってください。
Step 2. Mobile node runs IKE from care-of address B to the home agent, establishing a phase 1. The home agent can only act as the responder before it knows the current location of the mobile node.
2を踏んでください。 モバイルノードがIKEを実行する、注意、-、フェーズ1を確立して、ホームのエージェントにBを扱ってください。 モバイルノードの現在の位置を知る前にホームのエージェントは応答者として務めることができるだけです。
Step 3. Protected by this phase 1, mobile node establishes a pair of security associations for protecting Mobility Header traffic to and from the home address A.
3を踏んでください。 このフェーズ1によって保護されて、モバイルノードは、ホームアドレスとホームアドレスAからMobility Headerトラフィックを保護するために1組のセキュリティ協会を設立します。
Step 4. Mobile node sends a Binding Update and receives a Binding Acknowledgement using the security associations created in Step 3.
4を踏んでください。 モバイルノードは、Step3に創設されたセキュリティ協会を使用することでBinding Updateを送って、Binding Acknowledgementを受けます。
Step 5. Mobile node establishes a pair of security associations for protecting return routability packets. These security associations are in tunnel mode and their endpoint in the mobile node side is care-of address B. For the purposes of our example, this step uses the phase 1 connection established in Step 2. Multiple phase 1 connections are also possible.
5を踏んでください。 モバイルノードは、リターンroutabilityパケットを保護するために1組のセキュリティ協会を設立します。 トンネルモードでこれらのセキュリティ協会がそうであり、モバイルノード側のそれらの終点がそうである、注意、-、私たちの例(フェーズ1接続がStep2に確立したこのステップ用途)の目的をB.Forに扱ってください。 また、複数のフェーズ1接続も可能です。
Step 6. The mobile node uses the security associations created in Step 5 to run return routability.
6を踏んでください。 モバイルノードはリターンroutabilityを実行するためにStep5に創設されたセキュリティ協会を使用します。
Arkko, et al. Standards Track [Page 34] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[34ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
Step 7. The mobile node moves to a new location and adopts a new care-of address C.
7を踏んでください。 モバイルノードが新しい位置に移行して、新しい状態でaを採用する、注意、-、Cを扱ってください。
Step 8. Mobile node sends a Binding Update and receives a Binding Acknowledgement using the security associations created in Step 3. The home agent ensures that the next packets sent using the security associations created in Step 5 will have the new care-of address as their destination address, as if the outer header destination address in the security association had changed.
8を踏んでください。 モバイルノードは、Step3に創設されたセキュリティ協会を使用することでBinding Updateを送って、Binding Acknowledgementを受けます。 ホームのエージェントが、Step5に創設されたセキュリティ協会が使用させられた次のパケットが新しさを持つのを保証する、注意、-、それらの送付先アドレスとして、まるでセキュリティ協会における外側のヘッダー送付先アドレスが変化したかのように、扱います。
Step 9. If the mobile node and the HA have the capability to change the IKE endpoints, they change the address to C. If they do not have the capability, both nodes remove their phase 1 connections created on top of the care-of address B and will establish a new IKE phase 1 on top of the care-of address C. This capability to change the IKE phase 1 end points is indicated through setting the Key Management Mobility Capability (K) flag [7] in the Binding Update and Binding Acknowledgement messages.
9を踏んでください。 モバイルノードとHAにIKE終点を変える能力があるなら、それらはアドレスをC.に変えます。上、上、それらがするIfが能力を持っていない、両方のノードが創造された彼らのフェーズ1接続を外す、注意、-、Bを扱って、新しいIKEフェーズ1を確立する、注意、-、IKEフェーズ1エンドポイントを変えるアドレスC.This能力は、Key Management Mobility Capability(K)旗[7]をBinding UpdateとBinding Acknowledgementメッセージにはめ込むことで示されます。
Step 10. If a new IKE phase 1 connection was setup after movement, the MN will not be able to receive any notifications delivered on top of the old IKE phase 1 security association. Notifications delivered on top of the new security association are received and processed normally. If the mobile node and HA were able to update the IKE endpoints, they can continue using the same IKE phase 1 connection.
10を踏んでください。 1つの接続が新しいIKEフェーズであるなら動きの後のセットアップであった、ミネソタは古いIKEフェーズ1セキュリティ協会の上で提供されたどんな通知も受け取ることができないでしょう。 通常、新しいセキュリティ協会の上で提供された通知は、受け取られて、処理されます。 ノードとHAはモバイルであるならIKE終点をアップデートできました、とそれらが同じIKEフェーズを使用することで続けることができます。1つの接続。
7. Implementation Considerations
7. 実装問題
7.1. IPsec
7.1. IPsec
Note that packet formats and header ordering discussed in Section 3 must be supported, but implementations may also support other formats. In general, the use of formats not required here may lead to incorrect processing of the packets by the peer (such as silently discarding them), unless support for these formats has been verified off-line. Such verification can take place at the same time the parameters of the security associations are agreed upon. In some cases, however, basic IPv6 specifications call for support of options not discussed here. In these cases, such a verification step might be unnecessary as long as the peer fully supports the relevant IPv6 specifications. However, no claims are made in this document about the validity of these other formats in the context of Mobile IPv6. It is also likely that systems that support Mobile IPv6 have been tested more extensively with the required formats.
セクション3で議論したパケット・フォーマットとヘッダー注文をサポートしなければなりませんが、また、実装が他の形式をサポートするかもしれないことに注意してください。 一般に、ここで必要でなかった形式の使用は同輩(静かにそれらを捨てなどなどの)によるパケットの不正確な処理につながるかもしれません、これらの形式のサポートがオフラインで確かめられていない場合。 そのような検証はセキュリティ協会のパラメタが同意される同時代に行われることができます。 いくつかの場合、しかしながら、基本のIPv6仕様はここで議論しなかったオプションのサポートを求めます。 これらの場合では、同輩が関連IPv6仕様を完全にサポートする限り、そのような検証ステップは不要であるかもしれません。 しかしながら、本書ではモバイルIPv6の文脈における、これらの他の形式の正当性に関してノークレームをします。 また、モバイルIPv6をサポートするシステムは必要な形式で、より手広く検査されそうでした。
We have chosen to require an encapsulation format for return routability and payload packet protection which can only be realized if the destination of the IPsec packets sent from the home agent can
私たちは、リターンroutabilityのためにカプセル化形式を必要とするのを選びました、そして、IPsecパケットの目的地がホームのエージェントから発信した場合にだけ実現できるペイロードパケット保護は選ぶことができました。
Arkko, et al. Standards Track [Page 35] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[35ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
be changed as the mobile node moves. One of the main reasons for choosing such a format is that it removes the overhead of twenty four bytes when a home address option or routing header is added to the tunneled packet. Such an overhead would not be significant for the protection of the return routability packets, but would create an additional overhead if IPsec is used to protect the tunneling of payload packets to the home agent. This overhead may be significant for real-time traffic. Given that the use of the shorter packet formats for any traffic requires the existence of suitable APIs, we have chosen to require support for the shorter packet formats both for payload and return routability packets.
モバイルノードが移行するとき、変えてください。 そのような形式を選ぶ主な理由の1つはホームアドレスオプションかルーティングヘッダーがトンネルを堀られたパケットに加えられるとき、24バイトのオーバーヘッドを取り除くということです。 そのようなオーバーヘッドは、リターンroutabilityパケットの保護には重要でないでしょうが、IPsecがペイロードパケットのトンネリングをホームのエージェントに保護するのに使用されるなら、追加オーバーヘッドを作成するでしょう。 リアルタイムのトラフィックに、このオーバーヘッドは重要であるかもしれません。 より短いパケット・フォーマットのどんなトラフィックの使用も適当なAPIの存在を必要とするなら、私たちは、ペイロードとリターンroutabilityパケットのための、より短いパケット・フォーマットに支持を要するのを選びました。
In order to support the care-of address as the destination address on the mobile node side, the home agent must act as if the outer header destination address in the security association to the mobile node would have changed upon movements. Implementations are free to choose any particular method to make this change, such as using an API to the IPsec implementation to change the parameters of the security association, removing the security association and installing a new one, or modification of the packet after it has gone through IPsec processing. The only requirement is that after registering a new binding at the home agent, the next IPsec packets sent on this security association will be addressed to the new care-of address.
サポート、注意、-、モバイルノード側の上の送付先アドレスとしてのアドレス、まるでモバイルノードへのセキュリティ協会における外側のヘッダー送付先アドレスが動きのときに変化するかのようにホームのエージェントは行動しなければなりません。 実装は自由にこの変更を行うどんな特定のメソッドも選ぶことができます、セキュリティ協会のパラメタを変えるのにIPsec実装にAPIを使用するのなどように、セキュリティ協会を取り外して、IPsec処理に直面した後に新しいもの、またはパケットの変更をインストールして。 唯一の要件がホームのエージェントに新しい結合を登録した後に次のIPsecパケットが、このセキュリティ協会が新しさに演説されるのを転送したということである、注意、-、アドレス。
We have chosen to require policy entries that are specific to a tunnel interface. This means that implementations have to regard the Home Agent - Mobile Node tunnel as a separate interface on which IPsec SPDs can be based. A further complication of the IPsec processing on a tunnel interface is that this requires access to the BITS implementation before the packet actually goes out.
私たちは、トンネルのインタフェースに特定の方針エントリーを必要とするのを選びました。 これは、実装がホームのエージェントを見なさなければならないことを意味します--モバイルNodeはIPsec SPDsが基づくことができる別々のインタフェースとしてトンネルを堀ります。 トンネルのインタフェースにおけるIPsec処理のさらなる複雑さはパケットが実際に出かける前にこれがBITS実装へのアクセスを必要とするということです。
7.2. IKE
7.2. イケ
We have chosen to require that a dynamic key management protocol must be able to make an authorization decision for IPsec security association creation with different addresses than with what the key management protocol is run. We expect this to be done typically by configuring the allowed combinations of phase 1 user identities and home addresses.
私たちは、ダイナミックなかぎ管理プロトコルがかぎ管理プロトコルが何であるかという稼働したことであるより異なったアドレスでIPsecセキュリティ協会作成のための承認決定をすることができなければならないのが必要であることを選びました。 私たちは、通常フェーズ1ユーザアイデンティティとホームアドレスの許容組み合わせを構成することによってこれをすると予想します。
When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even with single certificates if they are large. Many firewalls do not handle fragments properly, and may drop them. Routers in the path may also discard fragments after the initial one, since they
証明書認証が使用されているとき、IKE断片化は遭遇できます。 証明書チェーンが使用されているとき、これが起こることができますか、またはシングルがあっても、証明書はそれらであるなら大きいです。 多くのファイアウォールが、適切に断片を扱わないで、それらを下げるかもしれません。 また、経路のルータが以来に初期のものの後に断片を捨てるかもしれない、それら
Arkko, et al. Standards Track [Page 36] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[36ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
typically will not contain full IP headers that can be compared against an access list. Where fragmentation occurs, the endpoints will not always be able to establish a security association.
アクセスリストに対して比較できる完全なIPヘッダーを通常含まないでしょう。 断片化が起こるところでは、終点はいつもセキュリティ協会を設立できるというわけではないでしょう。
Fortunately, typical Mobile IPv6 deployment uses short certificate chains, as the mobile node is communicating directly with its home network. Where the problem appears, it may be difficult (at least away from home) to replace the firewalls or routers with equipment that can properly support fragments. It may help to store the peer certificates locally, or to obtain them through other means.
幸い、モバイルノードがホームネットワークと共に直接伝達しているとき、典型的なモバイルIPv6展開は短い証明書チェーンを使用します。 問題が現れるところでは、ファイアウォールかルータを適切に断片を支えることができる設備に取り替えるのは難しいかもしれません(ホームから少なくとも離れている)。 それは、局所的に同輩証明書を保存するか、または他の手段でそれらを得るのを助けるかもしれません。
7.3. Bump-in-the-Stack
7.3. スタックで突き当たってください。
Mobile IPv6 sets high requirements for a so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As Mobile IPv6 specific modifications of the packets are required before or after IPsec processing, the BITS implementation has to perform also some tasks related to mobility. This may increase the complexity of the implementation, even if it already performs some tasks of the IP layer (such as fragmentation).
モバイルIPv6はIPsecのスタックのいわゆるBump(BITS)実装モデルに、高い要件を設定します。 また、パケットのモバイルIPv6特定の変更がIPsec処理の前または後に必要であるように、BITS実装は移動性に関連するいくつかのタスクを実行しなければなりません。 これは実装の複雑さを増強するかもしれません、既にIP層(断片化などの)に関するいくつかのタスクを実行しても。
Specifically, Bump-in-the-Stack implementations may have to deal with the following issues:
明確に、スタックのBump実装は以下の問題に対処しなければならないかもしれません:
o Processing the Home Address destination option and Routing header
type 2 to a form suitable for IPsec processing to take place.
This is needed, among other things, for the security association
and policy lookups. While relatively straightforward, the
required processing may have a hardware effect in BITS
implementations, if they use hardware support beyond the
cryptographic operations.
o ホームAddress目的地オプションとルート設定ヘッダーを処理して、IPsec処理が行われるのにおいて適当な2対1書式をタイプしてください。 これがセキュリティ協会と方針ルックアップに特に必要です。 比較的簡単である間、必要な処理には、BITS実装におけるハードウェア効果があるかもしれません、暗号の操作を超えてハードウェアサポートを使用するなら。
o Detecting packets sent between the mobile node and its home agent
using IPv6 encapsulation.
o パケットを検出するのは、モバイルノードとそのホームのエージェントの間でIPv6カプセル化を使用することで発信しました。
o Offering the necessary APIs for updating the IPsec and IKE
security association endpoints.
o IPsecとIKEセキュリティ協会終点をアップデートするために必要なAPIを提供します。
8. IANA Considerations
8. IANA問題
No IANA actions are necessary based on this document. IANA actions for the Mobile IPv6 protocol itself have been covered in [7].
どんなIANA動作もこのドキュメントに基づいて必要ではありません。 [7]でモバイルIPv6プロトコル自体のためのIANA動作をカバーしています。
9. Security Considerations
9. セキュリティ問題
The Mobile IPv6 base specification [7] requires strong security between the mobile node and the home agent. This memo discusses how that security can be arranged in practice, using IPsec. The security
モバイルIPv6基礎仕様[7]はモバイルノードとホームのエージェントの間の強いセキュリティを必要とします。 このメモはIPsecを使用して、実際にはどうそのセキュリティをアレンジできるかについて議論します。 セキュリティ
Arkko, et al. Standards Track [Page 37] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[37ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
considerations related to this are documented in the base specification, including a discussion of the implications of using either manual or dynamic keying.
これに関連する問題は基礎仕様に記録されます、手動の、または、ダイナミックな合わせることを使用する含意の議論を含んでいて。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[2] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[3] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[4] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[5] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[6] コンタとA.とS.デアリング、「IPv6仕様によるジェネリックパケットトンネリング」、RFC2473、1998年12月。
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] ジョンソンとD.とパーキンスとC.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
10.2. Informative References
10.2. 有益な参照
[8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[8] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[9] デアリングとS.とフェナーとW.とB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[10] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[10] Droms(R.(エド))はバウンドしています、J.、フォルツ、B.、レモン、T.、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、2003年7月。
[11] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[11] ビーダとR.とL.コスタ、Eds、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
Arkko, et al. Standards Track [Page 38] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[38ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
11. Acknowledgements
11. 承認
The authors would like to thank Greg O'Shea, Michael Thomas, Kevin Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel Montenegro, Steven Kent, and Santeri Paavolainen for interesting discussions in this problem space.
作者はこの問題スペースでの興味深い議論についてグレッグ・オシア、マイケル・トーマス、ケビンMiles、シェリル・マドソン、バーナードAboba、エリックNordmark、ガブリエル・モンテネグロ、スティーブン・ケント、およびSanteri Paavolainenに感謝したがっています。
12. Authors' Addresses
12. 作者のアドレス
Jari Arkko Ericsson 02420 Jorvas Finland
ヤリArkkoエリクソン02420Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メール: jari.arkko@ericsson.com
Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
ビジェイDevarapalliノキアResearch Center313フェアチャイルド・ドライブマウンテンビューカリフォルニア94043米国
EMail: vijayd@iprg.nokia.com
メール: vijayd@iprg.nokia.com
Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France
フランシス・デュポン・ENSTブルターニュCampus de悔悟de la Chataigneraie CS17607 35576Cesson-セビニェ・Cedexレンヌ2(フランス)
EMail: Francis.Dupont@enst-bretagne.fr
メール: Francis.Dupont@enst-bretagne.fr
Arkko, et al. Standards Track [Page 39] RFC 3776 Home Agent IPsec June 2004
Arkko、他 標準化過程[39ページ]RFC3776はエージェントIPsec2004年6月に家へ帰ります。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Arkko, et al. Standards Track [Page 40]
Arkko、他 標準化過程[40ページ]
一覧
スポンサーリンク
